Re: How Maven solves the problem of long builds on large projects?
On 21 Dec 2015, at 12:53, Sergey Saraev wrote: > I am developing a project with 67 modules. > I use Apache Maven 3.0.4. > > Reassembly of the project take 1 hour and 50 minutes although usually commit > change only one module. > > The project is very large. It contains 5948 java classes (Basically, time > spent on their compilation.). > Build command: mvn clean install pmd:pmd checkstyle:checkstyle > cobertura:cobertura Get rid of "clean" - that means completely delete all existing code and recompile from scratch, which you don't want. Get rid of pmd, checkstyle and cobertura until you need it. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [rpm-maven-plugin] how to control the name under which rpm is stored in m2 repository?
On 07 Dec 2015, at 8:44 PM, Steve Cohen wrote:
> Our organization has a convention for naming rpms. Typically, the rpm will
> have a shorter base name than the Maven project. There is also a convention
> around how releases are named. So we want a name
> like|${shortname}-${project.version}-${release}.noarch.rpm|.
>
> I want to build such rpms using the rpm-maven-plugin rather than older nmake
> technology.
>
> And this is easily accomplished using the plugin's parameters. The rpm
> generated in the target directory has the desired name.
>
> However, when|mvn install|installs this rpm into the maven repository, it
> insists on storing it the "maven
> way":|${project.artifactId}-${project.version}.rpm|
>
> I want the rpm stored in the standard maven repository directory using the
> name that is initially created on package.
>
> I also tried using the maven-install-plugin (install-file goal) and did not
> get the results I was after.
>
> How may I accomplish this?
You don’t change the name of a maven artefact, maven depends on this format and
you break maven if you try and change it.
Turns out yum is also very particular about naming formats, and is different to
maven. What we’ve done to solve this is to create hard links from the entry in
the maven repo to the entry in the yum repo, introspecting the RPM to work out
what the name should be, like this:
RPMDIST=`/bin/rpm -q --qf "%{DISTRIBUTION}\n" -p "${FILE}" | tr -cd
[:alnum:]`
RPMPATH=${YUMPATH}/${REPO}/${RPMDIST}/`/bin/rpm -q --qf "%{ARCH}\n" -p
"${FILE}"`
RPMFILE=${RPMPATH}/`/bin/rpm -q --qf
'%{NAME}-%{VERSION}-%{RELEASE}.%{DISTRIBUTION}.%{ARCH}.rpm\n' -p "${FILE}”`
To be even more specific, we do this automatically when artefacts are published
to our webdav server. We hang the following
script off Apache httpd’s reiiable piped logging feature which auto-processes
the file as soon as an upload is complete:
# reindex the yum repo on rpm PUT
CustomLog "|/usr/sbin/reindex-yum-filter-repo-greenhouse
/var/lib/httpd-repo-greenhouse/web-docs/maven2
/var/lib/httpd-repo-greenhouse/web-docs/yum" "%m %f"
Script is as follows:
#!/bin/bash
# Filter logfile lines from httpd-dev
#
# We are only interested in PUT requests, and we only consider the filename
# resolved by httpd, so we don't use any untainted input in this script.
#
# We extract the DISTRIBUTION (example: el6) and ARCH (example: x86_64, noarch)
# fields to determine the yum repo to link the RPM to.
MAVENPATH="$1"
YUMPATH="$2"
LOCK="/tmp/$0.lock"
trap "rm -f ${LOCK}" EXIT
while read LINE
do
if [ "x${LINE:0:4}" == "xPUT " ]; then
FILE=`/usr/bin/readlink -f "${LINE:4}"`
if [[ "${FILE}" =~ ^${MAVENPATH}/.*[.]rpm$ ]]; then
if [[ "${FILE}" =~ SNAPSHOT ]]; then
RPMREPO="snapshot"
else
RPMREPO="master greenhouse"
fi
touch "${LOCK}"
for REPO in ${RPMREPO}; do
RPMDIST=`/bin/rpm -q --qf "%{DISTRIBUTION}\n" -p "${FILE}" | tr -cd
[:alnum:]`
RPMPATH=${YUMPATH}/${REPO}/${RPMDIST}/`/bin/rpm -q --qf "%{ARCH}\n" -p
"${FILE}"`
RPMFILE=${RPMPATH}/`/bin/rpm -q --qf
'%{NAME}-%{VERSION}-%{RELEASE}.%{DISTRIBUTION}.%{ARCH}.rpm\n' -p "${FILE}"`
if [ ! -f "${RPMFILE}" ]; then
/bin/rpm -q --quiet -p "${FILE}" && \
/bin/mkdir -p "${RPMPATH}" && \
/bin/ln "${FILE}" "${RPMFILE}" && \
/usr/bin/createrepo -q --update --checkts
"${YUMPATH}/${REPO}/${RPMDIST}"
fi
done
rm -f "${LOCK}"
fi
fi
done
Regards,
Graham
—
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How easy/reliable is a maven repo hosted on webdav?
On 05 Nov 2015, at 2:13 AM, Kevin Burton wrote:
> I need to setup a new maven repo due to some changes we're making in our CI
> framework.
>
> Basically, I want something simple.. I was looking at bintray and
> artifactory and I think they are overkill for what we need and could be
> rather expensive per year.
>
> We already have plenty of hardware so I just want something simple.
>
> We used to use SCP but I don't want to give our CI hosting provider / SAAS
> the ability to auth into our cluster.
>
> WebDAV seems ideal because it could just work with plain old apache.
>
> However, I can't find any documentation for how to set this up.
I’ve used webdav based repos for years, and they work well.
On the server side you just need plain old Apache, secure with
username/password or certs (but if you use certs, make sure you use a version
of maven that supports them, some of the versions are broken with respect to
SSL handling with respect to certs and/or SNI)
In the pom, I have a distributionManagement section that looks like this:
repo.example.com
Example Repository
dav:https://repo.example.com/dev/maven2
repo.example.com
${project.name} Website
dav:https://repo.example.com/dev/docs/${project.artifactId}/${project.version}/
I’ve also used this extension, though not sure if it is still required:
...
org.apache.maven.wagon
wagon-webdav
1.0-beta-2
…
Regards,
Graham
—
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Why are extensions project based and not global?
On 28 May 2015, at 16:58, Manfred Moser wrote: > I think having a global config for this would be good. Personally I think > having .m2/extensions.xml would be a good way to do it. Can you describe the use case? It seems this only makes sense if you only ever do work for one organization, ever. As soon as you need to do work for multiple clients, or perhaps your corporate client and an open source project, using maven becomes difficult. Even with a single organization having config outside the project is a right pain. Instead of "it's maven, you know what to do", you have some weird site specific ritual to perform, and this creates friction. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Minimum RPM Version for rpm-maven-plugin?
On 06 Apr 2015, at 11:34 PM, Steve Cohen wrote: > I'm trying to run the rpm plugin on an old solaris box that is running rpm > v3.0.4, and the plugin complains that it can't find rpmbuild. IIRC, rpmbuild > was added to the rpm suite maybe 10 years ago and this is older than that. > Is that supported by the plugin and if so, how? The plugin requires rpmbuild in order to function. Is rpmbuild on the path? Regards, Graham — - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Name our mascot: "Shotgun" vs "The Maven Owl"
On 15 Dec 2014, at 12:39 PM, Stephen Connolly wrote: > After the run-off round, we are left with two names standing. > > This second vote will be a straight and simple majority wins. > > The vote will be open for at least 72 hours (with the potential of an > extension until I send a message saying that the polls are closed) > > There will be no discussion in this thread, we have talked it all enough > already. If you want to discuss something, please use a different thread. > > Vote: > > [A]: Shotgun > [B]: The Maven Owl > > Thank you very much for your time B. Regards, Graham — - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Run-off for mascot's name
Hi all, K. Regards, Graham -- > On 9 Dec 2014, at 10:52, Stephen Connolly > wrote: > > This is a run-off vote to select the top two options for our new mascot's > name. > > The entries with the highest number of votes will be selected for the final > round. If there is only one entry with the highest number of votes then the > entries with the second highest number of votes will also be included in > the final round. > > The vote will be open for 72 hours. > > The entries are as follows: > > A. Abraham > B. Boo > C. Darth Mowl > D. Jacob > E. Kaboom > F. Moses > G. Rap > H. Shotgun > K. The Maven Owl > L. Ty > > It is not clear whether all of the above suggestions were completely > serious, but I have included them anyway for this first round. > > Please respond with at most your top three in order of preference. I may > not use second or third preferences if we get a sufficient number of votes, > but in the case of a small poll the additional preferences will help. > > In the event of repeated votes from an individual, only the last cast vote > as determined by me will count. > > Any other discussion should happen in a separate thread. > > Thanks > > -Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with maven-deploy-plugin
On 14 Sep 2014, at 11:58, Fedor Belov wrote: > Hello. I've got repository protected by SSL located on subdomain: > https://abc.mysite.com/ > When I try to upload my artifact (`mvn deploy`) mvn rises an exception: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on > project test: Failed to retrieve remote metadata > abc.com:test:1.0-SNAPSHOT/maven-metadata.xml: Could not transfer metadata > abc.com:test:1.0-SNAPSHOT/maven-metadata.xml from/to myMavenRepo.write > (https://abc.mysite.com/efg/): hostname in certificate didn't match: > != OR OR -> [Help > 1] > > Why does it check main domain instead of subdomain? How can I fix this > problem? Either there is a server side problem where the cert on the server doesn't match the DNS name you're using, or more likely the server requires SNI, which doesn't seem to work with the httpclient wagon. We use the lightweight http wagon instead, which works with SSL+SNI. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Build once, deploy everywhere
On 10 Sep 2014, at 10:03, Jan wrote: > Does anyone using Maven as Build Once and deploy Everywhere method? Like > lets say i don't want to recompile my source code everytime for different > environment DEV,SIT,UAT & PROD. I want to do my compile and package only at > DEV then deploy the artifact to all mentioned environment. Is this possible > using Maven, is there any reference any one could share with me Please. We do this extensively with maven, using the maven release plugin. Our artifacts are in turn installable packages (rpms in our case, but could be deb, whatever) which get published into a yum repository. The code is "promoted" from dev to test to higher environments by hard linking the packages into distinct yum repos, a yum repo for each environment. The release created by the release plugin is built just once and promoted. The rpms are created using the rpm-maven-plugin. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Release Plugin - release:branch: branch versions not set as expected
On 1 Sep 2014, at 03:21, Mark Gibson wrote: > Ok, thanks Robert. > > Sadly this doesn't fit my expectations or needs. I'll look to do something a > little more manual. Are you perhaps mixing up tagging and branching? What you describe sounds like what release:prepare would do. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven + SNI == problems?
On 21 Aug 2014, at 5:07 PM, Martin Gainty wrote: > MG>The hostname that the cert is bound to != HostNameYouAreProviding > MG>determine the hostname which the cert is using and use that instead > MG>OR create a new cert from the key provided (jks)..here are the instructions > MG>http://docs.oracle.com/cd/E19798-01/821-1841/gjrgy/index.html > MG>pay particular attention to host= attribute which usually is localhost In this case the hostname the cert is bound to correctly matches the hostname I am providing, as this has been working fine for the last two years, and other versions of maven work fine. The latest version of maven doesn’t work at all. The current workaround is to drop wagon-http-lightweight-2.2.jar into the lib/ext directory, and SSL+SNI starts working again. To ensure everyone is on the same page, SNI is in use, and is described here: http://en.wikipedia.org/wiki/Server_Name_Indication Regards, Graham — - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven + SNI == problems?
Hi all, I just tied to do a simple “mvn install” against a long-since-working maven repository that is hosted on an SSL client-certificate protected server using SNI, and I get the exception below. I see in the stacktrace the default is httpclient, which has very patchy support for SSL/SNI. Is there a workaround to downgrade to a wagon that works with SSL and SNI? Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) Java version: 1.8.0_11, vendor: Oracle Corporation [ERROR] Failed to execute goal on project XXX: Could not resolve dependencies for project XXX:war:1.0.0-SNAPSHOT: Failed to collect dependencies at XXX:jar:1.23: Failed to read artifact descriptor for XXX:jar:1.23: Could not transfer artifact XXX from/to XXX (https://repo.example.com/XXX/maven2): hostname in certificate didn't match: != OR OR OR OR -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project XXX: Could not resolve dependencies for project XXX:war:1.0.0-SNAPSHOT: Failed to collect dependencies at XXX:jar:1.23 at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:220) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.apache.maven.project.DependencyResolutionException: Could not resolve dependencies for project XXX:war:1.0.0-SNAPSHOT: Failed to collect dependencies at XXX:jar:1.23 at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:167) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195) ... 22 more Caused by: org.eclipse.aether.collection.DependencyCollectionException: Failed to collect dependencies at XXX:jar:1.23 at org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:292) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:317) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:159) ... 23 more Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for XXX:jar:1.23 at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:349) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:231) at org.eclipse.aether.internal.impl.DefaultDependencyCollector.process(DefaultDependencyCollector.java:461) at org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:261) ... 25 more Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not transfer artifact
Re: How to avoid unzip of large test data on each "mvn test"
On 31 Jul 2014, at 2:55 PM, Francois MAROT wrote: > I'm in the process of switching to Maven for a large ANT project and have a > question regarding my test data. > I'd like those data to be versionned and stored in the Maven repo. But > currently those data are huge (let's say a 1-2 gigabytes once zipped). So I > imagine that if stored in the repo, each time I will run "mvn test" Maven > will have to unzip this big zip. It will take a lot of time... > Is there a best practise about it ? > Is there a way to store the data already unzipped somewhere and have mvn > test unzip the archive only if the version has changed ? > Any idea ? > > François > > PS: currently, the existing test code rely on the data being manually > unzipped once and for all at a hardcoded location on the disk :/ . Those > test data are currently not versionned (with all the related problems). Sounds like you want to treat this set of tests as integration tests, and then run them as required, rather than on every build. Any way to make these files smaller? Regards, Graham — - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why not a forum
On 22 Jul 2014, at 7:17 PM, Ron Wheeler wrote: > Not true. > You get an e-mail (individual or digest) that you can scan to see if you want > to participate in the discussion. > No more onerous than belonging to this group. > It also sorts out promotions and job offers from "real" discussions. You mean like a mailing list? :) Google does a way better job than any forum search function, and that’s the only meaningful feature in most forum software. Whenever I see a forum I generally ask “why not just a mailing list”? Regards, Graham — - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Property that indicates a snapshot or release build?
On 19 Jan 2014, at 6:20 PM, Anders Hammar wrote: > Don't understand. You need to, through code, get hold of the artifact > objects. I am trying to get access to this from a property. What I need is a property that I can embed in a path inside the pom. If the artefact is a release, the property is one value, while if the artefact is a snapshot, the property is another. The project.version property comes achingly close, but won't work for me because it will change on every release. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Property that indicates a snapshot or release build?
On 19 Jan 2014, at 5:59 PM, Anders Hammar wrote: > Yes, there is methods isSnapshot() and isRelease() if you get the Artifact > object. See [1]. > > /Anders > > [1] http://maven.apache.org/ref/3.1.1/maven-artifact/apidocs/index.html Is there a practical example anywhere of how this could be referred to from a maven variable? Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Property that indicates a snapshot or release build?
Hi all, Does there exist a property in maven that will indicate in some fashion whether the build is a snapshot build or a release build? I am aware that "-SNAPSHOT" appears in the version number, but that won't do. I'm after a variable that has one of two discrete values, one predictable value if it is a snapshot and another predictable value when it is a release. Does anything like this exist? Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: short and snappy description of what Maven is
On 06 Jan 2014, at 7:43 PM, "Lyons, Roy" wrote: > I would like to submit my short description for review. > > "Apache Maven is a convention-over-configuration build tool which has great > dependency management features." > > I know that it does more than that - but I feel that at its core, this is > what it really is. Big +1. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Opinion
On 05 Jan 2014, at 3:15 PM, Tommy Svensson wrote: > - You are forced to have a SNAPSHOT version even if you have no use for such. Maven works because there is a consistent level of standards and a consistent methodology, and these standards are enforced in central. If you pick and choose to ignore standards, you put the quality level of central at risk. Snapshots and releases are a fundamental part of maven, the maven system doesn't work without it. It is entirely right that central should block projects that refuse to follow the rules. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: release plugin, different executable name ('mvn3')
On 14 May 2013, at 10:02 AM, José Manuel Castroagudín Silva
wrote:
> This is what I'm seeing:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4.1:prepare
> (default-cli) on project : Failed to invoke Maven build.
> Error configuring command-line. Reason: Maven executable not found at:
> /bin/mvn -> [Help 1]
>
> (some specific details edited out)
>
> I was assuming that was the default behavior (as seen on
> http://jira.codehaus.org/browse/MRELEASE-428 ).
While maven doesn't care about the name of the executable used to run maven,
maven does care that MAVEN_HOME follows the correct structure, and it looks
like MAVEN_HOME isn't correctly laid out, most specifically that the bin
directory exists and has an "mvn" script in it.
In our case we have packaged maven to have an out-the-box MAVEN_HOME structure,
and then symlinked /usr/bin/mvn3 to ${MAVEN_HOME}/bin/mvn, and that worked for
us.
This seems to be a general maven problem, not a release plugin problem.
Regards,
Graham
--
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: release plugin, different executable name ('mvn3')
On 14 May 2013, at 08:31, José Manuel Castroagudín Silva wrote: > I've started doing some testing about maven-release plugin, and everything > went fine until the moment of trying it in our existing CI platform. Due > to, I think, "historical reasons", the maven executable is in this machine > named 'mvn3' and not 'mvn'. > > I've been looking around, and as for now, I would say there's no way of > telling the release plugin which executable to use. Is this so? Can you confirm what problem you are seeing? In theory, the release plugin shouldn't need to care what the name of the executable is. In our ci environment maven is also called mvn3, and it just works. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-plugin purge proper usage
On 12 May 2013, at 2:47 AM, Joe Osowski wrote: > Yes, you are correct. However, the problem with release/snapshots is that > maven assumes a revision in the VCS is a release. But in reality, a release > is the binary built by maven. A release is never just the binary built by maven, those are just bits, which can be rebuilt by maven at any time. Think of a release as something that can signed off, be it by a set of testers, or perhaps by someone doing due diligence with respect to intellectual property or license compliance, or perhaps as the entity that you delivered to the client. You can't sign off opaque bits, but you can sign off source code. > Using snapshots with multiple snapshot dependencies introduces changes at > release time that a release engineer has get to right, and mistakes will get > made. Exactly, and because of this all bets are off. A release in the maven world has a firm definition, it is a repeatable build, and a repeatable build cannot depend on or include any snapshot code. > The binary that is tested needs to be the release, not a binary that gets > generated after the release. For us anyway, I'm sure with fewer or no > snapshot dependencies it's different. If you're creating releases with maven ideally you should be doing this with the maven-release-plugin. This plugin performs a comprehensive set of sanity checks, and if the project passes a tag is created with a unique version number. As a second step the plugin then builds that pristine tag (and only that tag) after a clean checkout, giving you the guarantee that your binary matches the source code precisely. Most importantly the release plugin doesn't rely on humans following (or not following) a set of instructions, it is all completely automated and hands free. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-plugin purge proper usage
On 11 May 2013, at 10:17 PM, Joe Osowski wrote: >>> the build to make sure the latest dependencies are downloaded, as we >>> sometimes >>> change the non snapshot released binaries on our local maven repository. >> >> You do realize that this is a really bad idea, and it will eventually >> bite you, right? > > I can see why you would say that. We do weekly internal releases, using > snapshots introduces a lot of complexity into the release process across our > dependencies. What you're doing is trying to subvert releases and turn them into snapshots, instead of just using snapshots exactly as they were designed. Every new person to your project will see releases and assume they are, in fact, releases. Later, they will get a rude shock when they discover that what they thought was released code was actually snapshot code and sudden unexpected code changes and breakages appear. With no visible difference between a snapshot and a release, all bets are off. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
On 30 Apr 2013, at 11:21 PM, Roger Brechbühl wrote: > Maybe somebody is interested in how a release could be built in a more > lightweight and safe way than with the maven-release-plugin. Especially > recommended for nightly releases. > > It's not yet released, but basically fully working: > > *mvn clean install -Dversion.override=1.2.3-S-5* > > https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 Maven has a very clear definition of a "release", being an artefact that can traced back to the precise code via a tag, and a build that can be repeated. This is as opposed to a snapshot, which has no well defined origin. You might approach this two ways, you might create "nightly snapshots" and have them deployed somewhere suitable, using "mvn deploy". Alternatively if you want to create proper "nightly releases" (in the maven sense), you could feed a custom version number into the release plugin to represent your release, but this starts to smell like "that's what a snapshot is for". Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Why does the release process seem to require duplicate effort?
On 17 Apr 2013, at 7:34 PM, Russell Gold wrote: > Why does the normal release process require both release:prepare and then > release:perform? Under what conditions would you choose not to do the perform > step after a successful prepare step? Why do both generate source and javadoc > jars and prompt for the PGP pass phrase? The perform might require a special build environment, or you might perform many different releases (example unix, windows) from the same prepared source. If prepare and perform were welded together, this would become impossible. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Deployment
On 3 Mar 2013, at 16:24, Ron Wheeler wrote: > I have a hard time seeing how Maven can be bent to do this without making > maven even more complex. In my experience, maven has all the tools needed already out the box, the problems I encountered while doing it were bugs, which I fixed and contributed back to maven. Key to this is use the tools appropriately. Maven is good at building and releasing, rpm/deb/yum/apt-get are good for packaging and deployment, while puppet/chef are good for managing whole boxes. > I think that preparing deployment artifacts such as RPMs and windows msi or > exe files that are based in idividual platform and customer configurations > requires a lot more information than maven should know about. Configuration can be just as complex as code, you reach a point where constantly trying to roll configurations by hand is just too time consuming and error prone. Modern OSes come with the ability to install and roll back software atomically, extending that to configuration is a logical next step. The configuration may be general, or it may be specific to a given environment, either is possible. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deployment
On 3 Mar 2013, at 03:56, Eric Kolotyluk wrote:. >> Modern OSes come with installation systems out the box, and operations >> people already understand those existing systems, there needs to be a very >> compelling reason to deploy some software using the platform's own >> deployment mechanism, and other software via a different system. > > I wish this were so, but I can easily think of a half a dozen different ways > software gets installed or deployed on Windows. Some people use .msi files, > other people use InstallAnywhere, and there are all kinds of different > mechanisms. This isn't a problem that I can see, ideally maven should support all of them, but it is good enough that maven should support just one. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deployment
On 02 Mar 2013, at 5:40 AM, Eric Kolotyluk wrote: > I have been toying with the idea for a while as a software developer who has > had to build installers for applications and services, and I am often > dissatisfied with the experience I get using other people's installers. At > one time I was playing with the idea of my own installer that would be cross > platform, but the initial bootstrap would be platform dependent, and install > enough platform independent stuff, to do the rest in a standard way. Modern OSes come with installation systems out the box, and operations people already understand those existing systems, there needs to be a very compelling reason to deploy some software using the platform's own deployment mechanism, and other software via a different system. The deployment systems that are the most painful are those systems that target a specific language. You can't just get operations to install the software, you have to suddenly turn your operations people into language programmers to figure things out when a deployment goes wrong. Ideally I'd like to see maven make it easy to create OS specific installers to offer the best experience for each OS, rather than come up with a competing system. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Deployment
On 01 Mar 2013, at 11:26 PM, Eric Kolotyluk wrote: > A while back we had some interesting discussions on using Maven, or > maven-like technology for deploying production software. I was wondering if > anything new has been happening since then. > > Basically what I am hoping to see is a generic installer framework that > bootstraps deployment of a production system or service the way Maven > bootstraps a development environment. > > Can anyone point me to anything happening on that front? For a number of years now I've been involved in packaging the configuration of systems over and above the code of systems in the native format of that system, for Redhat derivatives that would be RPM. In other words, you deploy code packaged as an RPM, as well as configuration packaged as an RPM, and then you add the last very small details (passwords, certificates) via chef/puppet. Given that the majority of code we were building was built and released with maven, it was a natural extension that the configuration we were building was also built and released with maven, and so about a year ago I started getting the rpm-maven-plugin to build configuration RPMs. This effort uncovered a number of maven bugs, the clean plugin was found to be incapable of deleting symbolic links (it now can), and maven-filtering component used by the resources plugin couldn't escape the "$" character used in shell scripts (now it can), and the rpm-maven-plugin had various other bugs (now fixed). If you use the latest versions of the resources, clean and rpm plugins, building configuration packages as RPM works very well. Using native packaging formats built by maven means that from an operations perspective, the software and the code "is just a package" and therefore something operations people are likely to be able to work with and understand, and at the same time the building and releasing of these packages "is just maven" and are therefore something developers are likely to be able to work with and understand. In our environment, "deploy the production software" is just "yum install [production-software-config]". More importantly, "oh no, the upgrade broke everything" is responded to with "yum downgrade [production-software-previous-version]". Using this technique should also be possible with other systems like Debian derivatives, you would need to choose a maven plugin able to create Debian packages, but the principle is the same. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Packaging up pre-existing jar and source jar
On 17 Jan 2013, at 21:54, Joachim Durchholz wrote: > You two are really priceless. > > I have heard the message, I have requested concrete reasoning, yet all I get > is a pat on the shoulder and a commandment to shut up and believe already. > Four mails, and not a SINGLE concrete explanation what could (or will) go > wrong. Put yourself in the shoes of a brand new developer to your team. First thing you tell them is "we use Java 7". That's all you tell them. Java 7 is a known entity, they have never seen your system before ever, and yet that developer can bring their full past Java 7 experience to bear on your code, they get on with it, hitting the ground running. Second thing you tell them is "we use Maven 3". That's all you tell them. Maven 3 is a known entity, they have never seen your system before ever, but they already know how to build your code: mvn install, mvn release:prepare release:perform. They get on with it, hitting the ground running. Sometimes the developer hears "we build it with build.xml". Um, what? The developer can leverage nothing. Is your build.xml the same as past build.xml's? Nope. Can they type "build.xml" into google and get help? Nope. They have to waste time reading documentation that is only relevant to your site. Which no one bothered to write. So they reverse engineered build.xml to figure out how it works, just like they had to reverse engineer the last build.xml. Compiling code is a solved problem. You don't hire a developer and tell them you've made your own custom version of Java. Building code is a solved problem. You don't hire a developer and tell them you've made your own custom version of your build script. "But I might want to do X" says the naive developer. No, you don't want to do X, I the investor want you to use the standards already laid down by maven, I don't want you reinventing the wheel, and I don't want you to waste my money trying to re-solve solved problems. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site plugin to document properties in the pom?
On 14 Jan 2013, at 10:02 PM, Mirko Friedenhagen wrote:
> I once was successful with referencing injected properties in velocity
> by using the get method. Maybe something like:
> ${project.properties.get("tomcat.port.http.confluence43.live")}
> will work?
Alas, no.
The idea is that the properties in the pom and the properties published to the
site are always in sync, even after the current crop of architects have moved
on from the project. If you have to add a property in two steps, there is no
way the project will stay in sync.
Regards,
Graham
--
smime.p7s
Description: S/MIME cryptographic signature
Re: Site plugin to document properties in the pom?
On 14 Jan 2013, at 6:36 PM, Olivier Lamy wrote: > maybe > http://maven.apache.org/plugins/maven-site-plugin/examples/creating-content.html#Filtering Doesn't seem to fit, alas, as you have to come up with your own template and manually add the new properties to the template. In addition, my properties contain dots: 7999 7998 7997 127.0.0.1 Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Site plugin to document properties in the pom?
Hi all, I am looking for a plugin that will take the properties defined in the POM, and include these properties in the generated site. Does such a plugin exist? The problem I am trying to solve is that I have properties defined in a parent POM, and would like to expose these properties in documentation without manually copying the properties into a wiki or have some other manual process. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: [maven-3/trunk] bootstrap-build failing
On 01 Nov 2012, at 12:43 PM, "Stadelmann Josef" wrote: > What does that mean? > are you saying that maven developers will not fix the bootstrap-build problem > shown below or > are you saying that "This mailing list strips HTML" I have delivered > insufficient information? You have delivered insufficient information. HTML mail provides for different fonts and different colours, while plain text mail doesn't. HTML mail also provides a layout headache for makers of mailing list archiving software, and introduces all sorts of security headaches too, and so standard practise for many mailing lists is to take into account the text-only version of your email only. To see what your email looks like in the archives, see below: http://mail-archives.apache.org/mod_mbox/maven-users/201211.mbox/%3CC76B3518F981E0468383F7E091A595B88EFBE0%40c005815.chres1.doleni.net%3E As you can see, no red colour, so we have no idea what lines you are referring to. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Version ranges not working
On 28 Sep 2012, at 4:13 PM, Jesse Long wrote: > My library does clearly document the versions of slf4j it depends on - as a > version range in the pom.xml file. How else? > > Never mind slf4j for the time being, this affects all libraries. > > Please see http://semver.org/ > > The whole purpose of having a major version number is to clearly indicate > when incompatibility is introduced. It does get introduced, often. In turn, this is why maven goes on about repeatability - so that when you need to rebuild your code in an emergency to apply that critical bug fix to live, your code builds first time, every time. If you're someone like Redhat, and can hire a bunch of people to release packages with dependencies that follow the rule that ABI compatibility is maintained at all times, then you're fine. But if you're depending on various libraries released by various independent people and organisations with no guarantees of anything, then pinning the version numbers is the only sane thing to do. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Maven on a Terminal Server
On 28 Sep 2012, at 4:15 PM, Pascal Rapicault wrote: > I'm currently doing work for Ericsson where we have a similar setup (Terminal > Server on windows and AFS on *nix). > The difficulty in this setup is not network access but limited user storage > so the goal is to try to share as much as possible among the users. This was > such a concern for Ericsson that they built extensions to Eclipse to make > sure that users would not have copies of the plugins they install in their > user folder but would run them from a shared location. If you go down this road you have to be very careful - SNAPSHOTs are unsharable, because they are unrepeatable. I would be confused out of my mind if my perfectly working SNAPSHOT suddenly stopped working because it was silently replaced by someone else's SNAPSHOT. As to released artefacts these could be shared, this would be relatively easy to script. Have a "master" repository, and every so often sweep the local user's repos for files that are common in name and content to the master repo, then hard link a replacement. > Now to go back to Maven I can see how the desire to share artifacts applies > since I've had the same discussion last week :). Basically the local maven > repo is made of 3 things: > - released versions of non-corporate artifacts (e.g. content from > central, jboss, etc.) > - released versions of corporate artifacts > - snapshots versions of corporate artifacts > (yes there is snapshot of non corporate but I think they represent a > minority) > > Using this as a starting point, I think it would be possible to address this > in a clean way the problem if we were to make the local maven repository a > bit smarter (i.e. code change :)) . For example I think a solution that could > work is to have a read only shared cache that only contains the released > artifacts and have that chained to the local maven repository. This way when > an artifact is looked up, it is first looked up in the local cache, then in > the shared cache, and if it is not availble, then it is downloaded and stored > into the local cache (note that this solution of chained maven repo could > also be used to isolate snapshot from released artifacts) > > Since the shared cache is read only, its population could be done by doing a > dump of the repo manager content into the shared folder at regular interval. The trouble with this is that you still have to populate and maintain the shared cache on a regular basis, so you're doomed to some sort of scripting anyway. Keep all the magic in the script, and you don't have to touch maven at all. That means no special plugins, no maven behaviour unique to your environment, no documentation or training needed. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Exporting Individual Files with the SCM Plugin
On 27 Sep 2012, at 23:14, Christopher Gardner wrote: > I'd like to export a few jar files from an svn location. These jar files > are developed by other developers at my company and have no maven support, > and probably never will. Import the jars into your own maven repository, keeping your own copy. Configure your build as you normally would. Trying to bend your maven pom into something ugly goes against maven, rather keep things as clean as possible. If they don't version their artifacts, version them for them, but make it crystal clear where the artifacts came from. You don't want to rely on someone else's system that may or may not be available at a future date, and suddenly you're panicking because your code no longer builds. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Arguments for Maven vs. Gradle
On 11 Sep 2012, at 10:14 PM, Benson Margulies wrote: > I don't think it's useful to debate build tools and their builders or > tools on this list. I believe it is very useful. Many new users to maven don't fully understand the problem maven tries to solve, and a discussion like this one will hopefully shed more light on why maven approaches the build problem as it does. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Arguments for Maven vs. Gradle
On 11 Sep 2012, at 7:22 PM, Curtis Rueden wrote: >> Just let a few juniors touch the build and you are doomed pretty quickly. > > I agree, and would generalize this statement to any build system I've ever > designed or worked with: shell scripts, Makefiles, Ant, Maven... it doesn't > matter. A build is a very finicky thing, especially for medium-to-large > projects, and increasingly so as it adds gravy to the build process. A finicky build is a symptom of poor design, and if your design is poor no tool, unit test, CI, package, strategy or methodology is going to compensate for it. Discipline is the art of knowing why not to do something, and is a difficult thing to teach. There is a tremendous amount of waste that is perpetrated in software engineering, software is built to be disposable, with very short shelf lives. Maven challenges this trend by encouraging convention, repeatability, and code longevity, and this is a very good thing. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Is the release plugin intended to be run manually?
On 11 Sep 2012, at 6:02 PM, KARR, DAVID wrote: > I noticed a comment in > http://www.dzone.com/links/r/continuous_delivery_using_maven_3.html about not > using the release plugin because it checks in POMs after updating versions, > which isn't suited to a continuous delivery pipeline. Is the release plugin > intended to be run manually, and not part of an automated build? > > The documentation for the plugin doesn't really address this question. In theory, any plugin target can be executed as part of an automated build, the release plugin is no different. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Arguments for Maven vs. Gradle
On 9 Sep 2012, at 22:20, "KARR, DAVID" wrote: > One of the disadvantages of Gradle is the same as Ant, which is that it's > very easy to have two people do similar things in a completely different way. This to me is the fatal flaw in ant and all tools like it. Ant allows the developer to do whatever they like, and so they do, unnecessarily different to everyone else, and this difference must be debugged, documented and learned, over and over again, wasting countless hours and money. In contrast, Maven represents discipline. To understand maven one first has to understand discipline in software engineering, why there is no value in solving a solved problem in a way that is different but no better than solutions that have gone before. Why the best documentation is simply no documentation at all. Why the gift of a repeatable build is priceless to the person who has to fix a bug under stressful conditions. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release plugin: release project from within subdirectory
On 20 Jul 2012, at 6:10 PM, Kalle Korhonen wrote: >> Maven is about doing things the right way, no hacks. > > Says the purist :P This isn't purist, this is being disciplined. >> Hacks impede understanding of a project by others (or yourself 6 months >> later) and are an antipattern >> What happens when 6 months down the line you need a new feature and decide >> to upgrade the release plugin? You have relied on the hack, and the hack > > What happens when you are trying to deliver code but cannot because > the tool of the righteous doesn't work for you? Then you stop, you fix the bug, submit the fix upstream, and move on. I did that a few weeks ago with a problem I was having with the maven-resources-plugin (among others), I discovered my problem had been reported 5 years ago my more than one person, but nobody had spent the hour or so that it took to fix it. > Pragmatism always wins. Lack of discipline always wins. It drives me up the wall when I have to pick apart and undo some ugly hack that was put in place because someone wasn't willing to get the original job done properly, and I'm left forced having to debug the hack they put in place instead. When you encounter a problem that seems to need a hack, picture yourself in six months time, arms crossed glaring at yourself today, going "you could have fixed it and didn't, and now look at how I am suffering...". Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Maven for Software Installation
On 21 Jun 2012, at 20:53, Eric Kolotyluk wrote: > I have brought this notion up before, but I have been thinking about it a bit > more. > > Would it make sense to use Maven technology for software deployment and > installation as opposed to just builds? It definitely makes sense, and can be (and has been) done now without any modification to maven code or Apis. I designed a computation cluster for someone a few years ago that used a standard maven repo and part of the maven API to automatically resolve, download and install the nodes that ran the cluster. The client would say to the cluster, "dear cluster, please calculate this for me, using version x.y.z of model Z", and the cluster would download the code it needed where necessary. We no longer needed to upgrade or downgrade code, the cluster just did the right thing automatically. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven versioning
On 24 May 2012, at 4:23 PM, DK wrote: > So how does release work with SVN. > > If all my projects are at 1.0.0-SNAPSHOT. > What will running the mvn release command do? > > Will it result in 1.0.1-SNAPSHOT? Short answer is yes. Long answer: When you ask the release plugin to make a release for you, it performs the following steps for release:prepare: - Checks your code is properly checked in. - Checks your code builds. - Check your tests run. - Bumps the version number from the "snapshot" version 1.0.0-SNAPSHOT to the "release" version 1.0.0 in all affected poms and checks it in. On a multi-module project, this is done on all relevant poms. - Tags your release in SVN. - Bumps the version number from the "release" version 1.0.0 to the next "snapshot" version 1.0.1-SNAPSHOT in all relevant poms and checks it in, ready for further development. You now have a tag. Typically, the next step is to build and deploy your tagged release, which is done with release:perform: - Checks out a pristine fresh copy of the tag. - Builds the tagged code. - Builds the tagged docs. - Runs the tests. - Deploys the built code to the maven repo. - Deploys the built docs to the maven repo. And you're done. If for some reason any part of this process breaks (tests fail, build fails, couldn't contact the server, etc etc), you can roll the entire thing back with release:rollback. Once you've got this working, you will wonder how you put up with doing this manually. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Maven versioning
On 24 May 2012, at 2:39 PM, DK wrote: > Any best practices on changing version numbers? The best practice is to let maven worry about all of this using the maven-release-plugin. The plugin turns a release into a single command "mvn release:prepare release:perform", which becomes completely automated. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Feel Maven is not intuitive
On 23 May 2012, at 1:59 AM, hujirong wrote: > After working with Maven for a month, I am still not quite understand how > Maven works. Maybe just like Microsoft technologies, encapsulate too much. > One key issue is to understand the plugin. The way to think of maven is: "maven knows how to do stuff". Most specifically, each bit of "stuff" that maven knows how to do is implemented by a plugin. For example, maven knows how to compile Java code using the "maven-compiler-plugin". There are a host of other plugins that kick in when you build, each one doing one thing, that runs one after the other as part of a maven lifecycle. When you come to maven, don't ask the question "how do I...", instead ask the question "how does maven...". The reason the distinction is important is because maven already knows how to do something, you don't need to tell maven what to do, you just need to let maven get on with it. The vast majority of maven plugins don't need any configuration at all, they just know what to do. > For example, the following example, how can I see this thing allows JDK 5.0 > source. There is nowhere it says "allow". How do I know if it's not asking > the compiler to use JDK 5.0?! The mistake you're making is you're asking the question "how do I allow JDK source", so you're looking for an "allow" option and not finding one. What you should ask instead is "how does maven control the JDK source", the answer is by the maven-compiler-plugin the minimum levels by setting the following configuration option in the configuration for the maven-compiler-plugin: > >1.5 >1.5 > Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: The Maven Way
On 18 Apr 2012, at 1:44 AM, Eric Kolotyluk wrote: > Often the wrong foot is simply not knowing how much Maven does for your for > free - because it is not obvious - especially when compared to tools like > Ant. When the free stuff is not obvious, we naively start trying to solve > problems we do not have to. The way I describe this is by getting people to ask the right question: Wrong question: "How do I do X?" Right question: "Does does maven do X?" Maven already knows how to do stuff. Find out how maven does it, and let maven get on with the job. As soon as you want maven to work your way, and not maven's way, expect to have loads of your time wasted, and the time of everyone after you too. The next thing is that maven isn't an alternative to ant, rather maven is an alternative to ant's build.xml file. Or to put it another way, maven does what build.xml does. build.xml gets written, rewritten and rewritten again for every single ant project, but there is only one maven. I have to care how your build.xml is different to my build.xml, I have to document how your build.xml is different to my build.xml, but if we both used maven, all this becomes unnecessary, because there is only one maven. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Solve my exception for mvn installtion
On 16 Dec 2011, at 9:48 PM, Barrie Treloar wrote: >> I found the problem and now it is solved. >> >> thank all who helped me. > > This reply makes me angry. > > Please state what you problem actually was and what you did to solve it. > > The next person who has the same problem as you will hate you for not > posting this information. +1. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Continuous Delivery and Maven
On 13 Nov 2010, at 2:37 AM, Christopher Hunt wrote: Please correct me if I do not have this right, but in effect the requirement is to take a snapshot release, the developer do their testing and then, if satisfied, release it in effect by renaming the artifact to drop the "-SNAPSHOT"? My apologies if this is an over simplification, but if it is indeed the case then I think there is a flaw. Just because the developer has done their testing doesn't mean that everyone in the team has done their testing. One of the things that needs to be kept in mind also is that SNAPSHOT means the following: "All bets are off. This was probably created from someone's non- checked-in working copy. The build is definitely not repeatable, don't even try think it is, as if you do you're fooling yourself". Dropping the -SNAPSHOT just means mayhem. I think the cleanest way for maven to do CD is to create a plugin that slots in where you would normally use maven-release-plugin, and when invoked does this: - Checks out a pristine copy of the latest trunk or branch (or optionally a user specified revision). - Checks all files are checked in as maven-release-plugin does now, fail if not. - Sets the version number of the pom to match the revision number in scm, taking out the SNAPSHOT. - Runs the build. - Runs the tests. - Runs "mvn site" - Runs "mvn deploy" and "mvn site-deploy" Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Continuous Delivery and Maven
On 08 Nov 2010, at 7:03 PM, jhumble wrote: Two reasons: one, the faster you get feedback on the part of the story you have done so far, the faster you know if any further work is going to be valuable, and what in fact the next most valuable thing to deliver is. How do you handle branches? Second, most of the pain of the software delivery process comes *after* the software is dev-complete, during testing and deployment (often called the "last mile"). One of the important points of cd is that by creating deployable software with every commit, you avoid the pain at the end of the delivery process. We have an alternative approach to this that we've found works just as well if not better - we require our developers to integrate their own code into a package. Until the code has been packaged, the developer is not done. We've chosen RPM as our packaging format, but any format that is deployable atomically will do. We have further automated the deployments so that the packages are built in dedicated CI instances, in the process making it impossible for anyone to deploy anything that hasn't come out of source control first - no dodgy working copy builds or manual tweaking. We've banned deployment documentation - if you want it installed, you have to roll it into your package. If you want anything more sophisticated than "deploy this RPM, graceful restart this service", you have to justify it. We've found that doing this reduced costs on our platform by about an order of magnitude. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Replacing classes in a jar after bug fixes - patches
On 05 Nov 2010, at 2:20 PM, Barrie Treloar wrote: On Fri, Nov 5, 2010 at 9:36 PM, Salgar, Mehmet (external) wrote: Hi everybody, I have a question about how to replace a class in a dependency jar after a bug fix I made a fix for a class in a framework that is not developed from us, now during our build process I like to place patched class inside of original dependency So my question is there a maven plugin for this purposeI know, I can do this with maven ant plugin but I hoping may be there is a better way... The short answer is, No. Doing it that way is just asking for a world of pain. The correct way is to provide the patch back to the original project and then get a new release cut. While you wait for that to happen, create an internal release of that project that contains your patch. Following something like http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins (but it will be simpler since you are not patching a plugin) I can't stress the pain this causes enough. It's bad enough when you're forced to get a version of production code up and running to fix a bug. When that code suddenly exhibits a new bug, because the magic version of some nameless jar is suddenly different, but it's completely impossible to tell they are different, you risk losing the will to live. Please, don't do it. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
On 26 Oct 2010, at 8:56 PM, Kenneth McDonald wrote:
Yeah, but a build often does not fit on a page, and I'm building
some pretty simple stuff!
To argue for the flexibity of Maven is (AFAIK) defensible. It's
power (from what little knowledge I have), likewise.
But, I'm sorry to say, the verbosity of XML is a major, major issue.
You've said that a number of times, but I haven't yet seen a solid
justification for it. For me, it's a non issue. If it doesn't fit on a
screen, I scroll down. I can scan and read if by hand if I need to,
but way more often, I validate the structure against an XSD, and the
system finds my mistakes for me. And I never see any need for this:
foo() {
.
.
.
} /* foo */
I leave my pom files to the defaults as far as possible, and that
means options aren't set. Those that are set are neatly sectioned off,
with comments if necessary to explain something that may not be
obvious to the eye.
The code is in a separate project to the archive (jar, war, etc),
which is in a separate project to the assemblies. When the pom gets
too long, it's a clear sight the project should be broken up into
smaller more manageable pieces. Sometimes these are all released
separately with different version numbers, most often they all share
the same version in a multi module project. I don't know or care,
maven-release-plugin cares about version numbers.
I get the sense that you're bitterly opposed to XML, and by extension,
anything else that uses XML, and while maven uses XML, you'll be
opposed to maven. This is not a problem maven can fix for you.
I bring you back to the simple fact of: If XML were so expressive,
why aren't most modern languages written in XML?
Because if language designers agreed on a common syntax they would
have also agreed on a common language?
You're again making a mistake that maven pom files are somehow a
"language", in the way that ant build files are.
Pom files are a hierarchical collection of facts, they are not a
sequence of instructions. XML is really good at solving this problem.
Maven is not ant.
I've looked at pages and pages of POM files, trying to learn things.
And my conclusion is that Maven was _fundamentally flawed_ in
choosing XML as its base.
They had to choose something, and the world didn't need another custom
syntax.
Regards,
Graham
--
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
On 23 Oct 2010, at 11:15 PM, Kenneth McDonald wrote: Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. What "maven pom files are declarative" means in English is that the pom file contains facts about your project, "nouns". If your pom files contain "verbs", then you're doing it wrong. The "verbs", or "what maven knows how to do", should be embedded within plugins, not shoehorned into the pom file. For examples of maven used correctly, download some of the maven plugin projects and see the way they're put together. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
On 20 Oct 2010, at 1:17 PM, Martin Gainty wrote: IDEs from my experience are tools to create (workspace) environments and to create xml scripts to compile, package and deploy wars and ears the useful life of an IDE passes when the webapp is promoted to production and the op implements the goals in the pom.xml to deploy to appserver What you're describing sounds monolithic. Any great big monolithic application is going to be painful to manage, and maven won't be able to help you if you try have one pom file to rule them all. Break your projects into bits, and then assemble the bits at the end in a separate project. Then in a separate project again, configure the magic install behaviour that you want. When your project is made of many bits, you want to be able to repeat your build - maven steps in and ensures that everything is pinned to the correct dependencies correctly. Maven only does this however if you've asked it to. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
On 14 Oct 2010, at 7:00 PM, Leon Rosenberg wrote: This isn't quite true since ant allows you to build 'your own maven' in few hours. The effort to learn maven is much higher, at least I had to spend a lot more time since now. On the other side the effort to learn ant is moderate. But maybe I'm biased here ;-) Reading this, it's like saying "I hear you're building an airplane in your garage, why all the trouble? You just take this piece of paper, and fold it like this...". And, you can't deploy with maven... mvn deploy? Which you would never do manually, because deployment is done automatically during "mvn release:perform". Well actually what bothers me is that my build scripts very shorter than my poms. My typical build script in my pre-maven time was 3 rows long: Now take a look at this from the point of view of somebody who has never seen your ant project before. They check the project out, they see "build.xml", they than go "oh cool, an ant build, let's try 'ant install'". Error. Oh, it's complaining about a file that doesn't exist in a directory I don't have, no idea why, let me try and reverse engineer the ant script. Oh look, I have to check out something else and stick it in some directory structure. Oops, I already have a build directory, let me rearrange the directories on my disk. Right, it's checked out, let me try that again. Error. Oh, what is it this time. Reverse engineer the basic-project.xml. Oh, they've called it "ant jar" for some reason, which was different to my ant scripts from the other project, where it was 'ant install'. Let me try "ant jar". Error. Oh for crying out loud. Reverse engineer the basic-project.xml. Discover that someone made a change to the shared ant script to fix the requirements of project Y, but that has broken project X. Let me try and hack it to work. Ooh look, it works now. Later, you check out project Y, and you try and build it. Error. Guy who wrote ant build script is spontaneously thrown out of the third floor plate glass window. In comparison, I might check out your project, look in the root of the project and see "pom.xml". "Oh, cool, a maven build, let me go 'mvn install'". Done. Well thats another point, what if I have more than one source code directory? For example I have a project which contains an apt-based code generator. You don't know, and you don't care, because the maven plugin that knows about apt-based code generation worried about that for you, that's its job. I have some projects that use the Torque database code generator. The plugin has a default location it places the classes, and it tells maven, and that path automatically appears in my Eclipse project when I ran "mvn eclipse:eclipse". Again, I didn't know it was doing this and I didn't care. I was too busy getting on with the job at hand with code. At the core of ant is the question "how do I make ant do this?". At the core of maven is the question "how does maven do this.". Remove the "I" from the equation, and just do it like maven wants you to do it, and suddenly everything becomes a *lot* more reliable. I don't know.. I have use-cases over use-cases with stuff that maven isn't doing per default. Stop and think about that for a bit. Do you really have this use case, or is it a nice to have? Example: get cobertura/findbugs/pdm reports without site phase. I actually expect the CI to call verify instead of building a site. I spent three days trying to get a cobertura report out of verify and finally gave up. I type "maven cobertura plugin" into Google. On the opening page of the first hit, under "goals overview", I see "cobertura:cobertura". I run "mvn cobertura:cobertura". Done. Example: pack and unpack additional files into jar files. We have a project which is an embedded-tool for webapps, similar to tomcat-manager, but inside the webapp. We are used to package it as jar and include jsp/img/js/css files into it, and unpack them in the process of building of the final war. Manageable with maven? Yes, but a lot of code. Why are you trying to insert additional files into jar files? When you build the jar file, use the maven-resources-plugin to insert the additional files in the right place from the default src/main/ resources directory. Once released, the jar is sealed, you don't touch it again. Fiddling with jars after release is evil beyond words. I was involved in an outage where we had to get the code running in production up on a developer machine to reproduce a bug. Oops, the code didn't build. How on earth did code that didn't build end up in production? Sheepish admission from project developer: "I might have added an additional file to the jar after the release was finished, as I didn't want to bump the version number". Don't do it. And than this uncertainty. We need to add some files to the war.
Re: maven is a swamp
On 13 Oct 2010, at 10:52 PM, Wendy Smoak wrote: Help with the website is always welcome. The source code for the website is here: http://svn.apache.org/repos/asf/maven/site/trunk/ The home page is down at http://svn.apache.org/repos/asf/maven/site/trunk/src/site/xdoc/index.xml.vm (Most other pages are under src/site/apt). If you need help editing/building/submitting a patch, come join us on the dev list and ask. (Graham, would you be okay with having your post adapted for the website, should someone have the time and energy to work on it?) Definitely. I think some key points maven needs to make are these: - "Maven already knows how to do stuff. Now step aside, and let maven do what it has to do, don't get in maven's way". - "You don't need to customise maven to fit your project, customise your project to fit maven". - "If you need to document your build, you're doing it wrong". Maven knows how to do stuff. So do developers who know how to use maven. If you've used maven correctly, you don't need to document anything at all. You tell your new developer "here's the URL of the maven- generated site, off you go". The developer knows where on the site to find the location of the project in SCM. The developer checks out the project. The developer knows how to build the project. The developer knows how to obtain all the dependencies. The developer knows how to release the project when they're done. The developer didn't need to read a single piece of documentation that wasn't autogenerated for your project. As soon as you need to start documenting things, you're starting to go wrong. Practically, you may have to document some things, such as where to get certificates for access, but you should strive to keep this documentation to zero or as near zero as humanly possible. Documentation costs money to write, it costs money to read, it costs money when someone missed the vital bit of the documentation and things go wrong. This is where the "configuration by convention" really shines. If you know the convention, you don't need to waste time with documentation, troubleshooting, customisation, you just get on with it. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
On 13 Oct 2010, at 8:52 PM, Leon Rosenberg wrote: Many traditional programming languages are declarative and not procedural or are based on declarative concepts, most of the time the declarative nature of such languages proved itself problematic. But seriously is there a comparison matrix somewhere which compares ant+ivy vs maven? A comparison would make little sense, because ant and maven aren't alternatives for one another. Ant is a language that allows you to create custom build scripts, but you are required to write those build scripts yourself, over and over again. Maven on the other hand arrives with built in knowledge on how to build things, you are only required to tell maven the basics, like the name of the artifact, the version, etc. Maven does everything else for you without you having to tell it how to do it. As an ant+ivy user I have recently tried out maven (yes, i hand-wrote poms for about 15 projects) which mostly depend on each other, I got them all published in nexus etc. I must say that I'm pretty shaken how unreliable maven build are. I predict the core of your problem is "as an ant+ivy user...". With ant, you adopt the mindset "I need to tell ant to do X, then Y, then Z". With maven, you don't tell it how to do anything, it already knows how to do stuff. If you try and approach maven with the idea that you want to tell maven to do X, Y and then Z, you'll very quickly come unstuck, because you'll be fighting with maven, trying to convince it to do things in your order instead of maven's built in order. Maven already knows how to do stuff. All you need to do is fill in the blanks. Tell maven what kind of artifact it is, what it is called. And don't stray from the defaults - you don't need to put your source code in some weird directory structure, if maven defaults to src/main/java, put your code in src/main/java and leave it at that. When you find yourself in a situation where you have a 5 line pom file, with hundreds of plugins all custom configured, you're fighting against maven. This isn't maven's fault, this is the fault of the person who created the pom. Keep it simple, keep it to default behaviour. With ant it either works or not. If it works, it works everywhere, in console, in eclipse in hudson. In my experience, I have not once encountered an ant build that worked, ever. The reason was simple: the build is always secondary to the code itself. Inevitably, the ant build only performed the basics, even "ant clean" was left out most of the time. Every single one I encountered had some or other path that was hard coded to "C:\Program Files\..." with the developer expecting everyone else to just recreate the same directory structure, it was ridiculous. Maven has gone off and solved the build problem, it does not rely on every developer's half hearted attempt to write a build script when they're under pressure to produce code, not build. At the core of ant is the question "how do I make ant do this?". At the core of maven is the question "how does maven do this.". Remove the "I" from the equation, and just do it like maven wants you to do it, and suddenly everything becomes a *lot* more reliable. I find it pretty hard to maintain versions with maven. Do I have to make them all depend on RELEASE version of each other? Yes. The whole point of maven is repeatability. What that means practically, is that ops call you and say "we have problem X in production, v2.3.4 of the code, can you fix it". If you cannot get v2.3.4 of the code - and by that I mean precisely v2.3.4 of the code - up and running in your development environment, you're toast. To do that, v2.3.4 of the code must be built against a pristine tag. And v2.3.4 of the code must depend on other jars who were also built from a pristine tag. What a SNAPSHOT is is a great big red flag that says "ALL BETS ARE OFF". SNAPSHOTs are built from random untraceable working copies. You should *never* allow a SNAPSHOT to find its way into production. When you use the maven-release-plugin (and you should), it performs all the checks and balances to verify that your build is entirely free of SNAPSHOTs, and that your code is checked in cleanly. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release Plugin Explained?
On 15 Jun 2010, at 4:16 PM, dawi...@gmail.com wrote: Where do I find basic guide on the release plugin? Have you found this yet? http://maven.apache.org/plugins/maven-release-plugin/ Reference information on Apache's website is good but I would like to understand the philosophy behind the process. The basic philosophy is that the release plugin manages releases, you don't. Or to put it another way, no custom weird procedures, no weird scripts, only one procedure consisting of two steps: mvn release:prepare release:perform The first part, release:prepare, does all the preparation for, and tagging your release. Lots of checks and balances, like "is your code checked in", "does it build", "does your test suite run", followed by the creation of the tag, and the bumping of the version numbers in all the poms. The second part is the bit that does the build itself, from the tag created earlier. This is done as a separate step, as your build might be platform specific, and need to run on another target machine. How should I manage versions, the scoop behind snapshots, how an SCM figures into this picture, best practices etc. I suspect Nexus is a great tool to do all that however I can't install it due to corporate policy. If your pom is properly configured with the correct scm details, etc, the the release plugin will just work. In practice, you may find while attempting to run the release plugin that your pom metadata isn't accurate, but this is easy to fix - just fix each problem as it arises. Once the release plugin runs clean end to end, you're done. While experimenting, you may want to try and rollback a release that bombed out halfway through. "mvn release:rollback" should do the trick, allowing you to try again. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Documentation help
On 07 Apr 2010, at 6:56 PM, Lorenzo Thurman wrote: I've looked at a couple of the docs at the website, "Getting started in 5 minutes" and "Getting started in 10 minutes", but I'd like to find something a bit more comprehensive. For example, I was trying to build and test a simple project with only two files, MathFunctions.java and MathFunctionsTests.java. The compile ran just fine, but the unit tests were not run. I eventually figured out that my unit tests source needed to match the name of the code source with the word Test appended to the name, so after renaming my unit test file to MathFunctionsTest.java, it ran just fine. I'm sure something simple like this is documented somewhere, I just don't know where. Mind you, I'm still fairly new to Java programming and environments such as Maven, so I think I'm going to need some hand holding, so if such a naming convention is considered standard, I was unaware. The general pattern by which maven works is that anything that maven can do, is done with a plugin, so the question you typically find yourself asking is "which plugin does X for me?". In the case of the compile, the maven-compile-plugin does the job for you out the box with default values, which is why it "just worked". In the case of running tests, the maven-surefire-plugin does the job for you, and it by default will run any test that matches a standard naming convention. You needed to figure out what that naming convention before it would work. Once you know the name of the plugin that does what you need, the next step is to find the documentation for it, and usually a google for "maven foo plugin" will do the trick. What you're encouraged to do is stick with default conventional behaviour wherever you can. In other words, if maven wants you to name a file a certain way, or look for a file in a certain directory, stick to the defaults. If you do, most stuff should just work without any modification. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-rpm-plugin + uniqueversion = fail
On 06 Apr 2010, at 9:19 AM, Stephen Connolly wrote: at the XPath /project/distributionManagement/.../uniqueVerision In your project, you set it to false and then when your project is deployed to the repo, it will not use timestamped SNAPSHOTS I've tried that, and it didn't seem to work - maven-rpm-plugin ignored the flag and tried to use timestamps anyway. Going back version by version through maven-rpm-plugin showed that v2.0-beta-4 was the last version of the RPM plugin that worked, I've raised the problem as http://jira.codehaus.org/browse/MRPM-70. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-rpm-plugin + uniqueversion = fail
Hi all, I am having trouble with the maven-rpm-plugin and maven v2.2.1. maven-rpm-plugin is correctly creating an RPM, but the RPM has the wrong name. As a result, the attempt to copy the RPM into the repository fails with the error that the file does not exist. The component of the RPM name that is wrong is the timestamp that has suddenly appeared at the end of the name. It seems that somewhere the name of the artifact is being generated more than once, and as the timestamp changes between these two attempts to generate the names, this is the cause of the file not existing. What I would like to do is switch this strange timestamp feature off completely, as it doesn't seem to work. I can pass an option to maven on the command line, but what I am missing is how to turn this off in the pom itself. All I can find is a reference to the uniqueVersion in the distributionManagement section, which makes no sense to me at all. I just want to switch it off for the project, not for the repository it will be uploaded to. Does anyone know how this feature is switched off? Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: General questions regarding dependencies
Doug Hughes wrote: > I have some questions about how dependencies are handled within Maven. I > understand that when you add a dependency that Maven looks at the central > repository, finds the correct files and downloads them. I'm wondering if > this can only be done for JAR/WAR files? No, any artifact from your build can be deployed into a maven repository. The maven-rpm-plugin for example creates an RPM file as an artifact, and the maven deploy step will deploy the RPM into a repository, it doesn't have to be a jar or a war (or an ear, or whatever). > My question then is, is it possible to somehow define a dependency which is > a collection of files? Yes, group the files together into some kind of archive (zip is good, or jar seeing we are in the java universe), and then deploy that. > Also, if I did somehow define that dependency, is > there a way to make sure that the dependency is coppied to a specific > directory within he webapp? Yes. The maven-dependency-plugin can be asked to unpack directories and put them in certain places during your build. Alternatively, for more general purpose stuff, the maven-assembly-plugin can be used to produce an "assembly" of multiple things combined into a single tree. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Adding system scope jars to the manifest class path
Graham Leggett wrote: > The core reason is that it's virtually guaranteed that someone else, on > a different machine, will want to build you code, and if the jars are on > a shared repository (public or private, maven does care), then this is > trivial and automatic. you == your does == doesn't Sigh, need more coffee. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Adding system scope jars to the manifest class path
Kogel, Jonck-van-der wrote: > Ok, allow me to rephrase :) I'm struggling with some proprietary (IBM, > Oracle, etc..) jars that I need to get added to my manifest class path. > I don't want to do that manually obviously. When I add the proprietary > jars to my pom and set their scope to default level, when I try to build > Maven complains that it can't find the proprietary jars in any of the > public repositories. I have added the jars to my local repository and > correctly set the directory structure to match my pom but to no avail. > So I googled and read that the way round that is to set the scope to > system. But then the jars don't get added to the manifest class path > anymore. So I guess my question is: how do I set it up so that Maven > only looks for proprietary jars on my local repository and doesn't try > to go outside and look for them? Ideally you should run your own private repository and publish the jars there. At the most basic level, this repository is just a webserver, so it doesn't require much setup. This repository starts becoming important when you start using the release plugin to make your releases, your code will then be uploaded automatically to your same private repository. The core reason is that it's virtually guaranteed that someone else, on a different machine, will want to build you code, and if the jars are on a shared repository (public or private, maven does care), then this is trivial and automatic. Trying to maintain your own private directories of jars causes pain that maven steers you away from. Taking the effort to set up a private repo in the beginning will make your life significantly easier down the line. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: LATEST and RELEASE release version management
Hayes, Peter wrote: > We use Maven in an enterprise environment and internally we are required > to execute "release" builds whenever we want to install to our testing > environment. We have found that executing many release builds can be > tedious when we have in-development snapshot dependencies that also have > to be released. We don't mind doing the releases, but the manual > version update -- release -- revert version cycle is a chore. > > I was hoping that Maven could simplify this by allowing a project to > declare a dependency on LATEST or 1.0-LATEST and have the maven release > plugin resolve this to the actual latest released version available in > the repository. The subsequent fully resolved pom would then be > uploaded to the internal repository and the pom left in source control > still references LATEST. > > Does maven already support something like this or would others find this > useful? Having a LATEST concept would be very useful for something like continuous integration builds, where the desire is for a project to depend on the latest version of another project (release or snapshot), rather than a specific version of another project, so that you can see what errors have been introduced or that should be allowed for. Having said that, it makes no sense to have the release plugin care about LATEST, because by definition, building against LATEST isn't repeatable, and in order for there to be a release, you need the build to be repeatable. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANN] Maven Release Plugin 2.0-beta-9 Released
Todd Thiessen wrote: The part where it says how to make a complex tag. ie: making a tag from a working copy. A complex tag refers to ways of making a "snapshot" of a specific working copy, quoting specifically "which is an exact snapshot of your working copy—mixed revisions, URLs, and all". Trying to make a release from such a "snapshot" is a fundamental contradiction in terms in the maven world, and very bad practice. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANN] Maven Release Plugin 2.0-beta-9 Released
Todd Thiessen wrote: Not according to svn. http://svnbook.red-bean.com/en/1.1/ch04s06.html That's the docs for tags, which part of those docs are you referring to specifically? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANN] Maven Release Plugin 2.0-beta-9 Released
Todd Thiessen wrote: Yes you can. See svn documentation: http://svnbook.red-bean.com/en/1.0/re07.html In particular, the WC -> URL case. You've posted the docs for the svn "copy" command, a "tag" only formally exists when you use the URL -> URL case. In the case of the WC->URL case, as I read it, it is simply a shorthand way of saying "add" followed by "commit" of a single file. The docs don't clarify whether any history is kept, or whether any requirement exists for the WC file to be checked in or up to date first. A tag without history isn't a tag. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANN] Maven Release Plugin 2.0-beta-9 Released
Todd Thiessen wrote: So if I understand remote tagging correctly, this means that a tag is taken > off the trunk, not the working copy. You can't (to my knowledge) tag a working copy, that doesn't make any sense. Can you clarify? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Despite trusted CA, "unable to find valid certification path to requested target"
Brian E. Fox wrote: The CA may be trusted, but the site needs to expose the full signature trail from the server cert up to the CA. Not doing this will often cause the site to appear ok in a browser, but not to java. Most SSL signing authorities provide a bundle that you can set on the server side. In this case, the cert is signed by the CA directly, the full chain is just two certs long. Trying the same config under Linux works fine, with the same certs, project and site. Regards, Graham -- -Original Message- From: Graham Leggett [mailto:minf...@sharp.fm] Sent: Sunday, March 29, 2009 1:14 PM To: users@maven.apache.org Subject: Despite trusted CA, "unable to find valid certification path to requested target" Hi all, I am having trouble getting mvn site:deploy to work with mvn v2.1.0 (also v2.0.6), as follows: Embedded error: Failed to create destination WebDAV collection (directory): /docs/stencil/0.0.1-SNAPSHOT/./apidocs unable to find valid certification path to requested target The machine is a MacOSX machine, and a search turns up three different copies of the cacerts database (one for v1.4.2, one for 1.5.0 and one for 1.6.0). The CA cert for the DAV webserver is present in all three cacert databases, and to be sure I physically removed and re-added the CA cert to all three databases, with no luck. From the symptoms I am seeing, it looks like none of these three cacert databases are being used at all, and the JDK is using a mystery or missing database of its own. Can anyone confirm whether maven does any weird or special handling of cacert databases on MacOSX, or does it just revert to the JDK default on the platform? Is there a way to see what CA cert database is being used by maven when it runs? (It's obviously not using any of the cacert databases I've added the CA cert to, or it would work). Anyone ever solved a problem like this before? Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org smime.p7s Description: S/MIME Cryptographic Signature
Despite trusted CA, "unable to find valid certification path to requested target"
Hi all, I am having trouble getting mvn site:deploy to work with mvn v2.1.0 (also v2.0.6), as follows: Embedded error: Failed to create destination WebDAV collection (directory): /docs/stencil/0.0.1-SNAPSHOT/./apidocs unable to find valid certification path to requested target The machine is a MacOSX machine, and a search turns up three different copies of the cacerts database (one for v1.4.2, one for 1.5.0 and one for 1.6.0). The CA cert for the DAV webserver is present in all three cacert databases, and to be sure I physically removed and re-added the CA cert to all three databases, with no luck. From the symptoms I am seeing, it looks like none of these three cacert databases are being used at all, and the JDK is using a mystery or missing database of its own. Can anyone confirm whether maven does any weird or special handling of cacert databases on MacOSX, or does it just revert to the JDK default on the platform? Is there a way to see what CA cert database is being used by maven when it runs? (It's obviously not using any of the cacert databases I've added the CA cert to, or it would work). Anyone ever solved a problem like this before? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Keep version when doing a release
[EMAIL PROTECTED] wrote: I have a multi module project that I want to make a release for. Some of the modules changes frequently and they are marked as SNAPSHOTS. Some modules are very stable and have a fixed version. I run maven 2 release plug-in 2.0-beta-7 with the --batch-mode parameter. The problem is that the stable modules will also have there version upgraded. Is there any way to tell the plug-in to only change version for SNAPSHOT modules? Break up your multi module project into a smaller set of multi module projects. I had a project like this a while back, and I defined some variables in the super pom of multi module project B to point at the version number of multi module project A. This eliminated confusion over what relied on what, and ensured that the dependency was defined in just one place only. The more code you release at one time, the more difficult it is to tell where a bug might lie. Spin off the stable stuff into their own release cycles, and your troubleshooting problems will become significantly less, as a problem will most likely be caused by a smaller subset of newly released code. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Third party jars
[EMAIL PROTECTED] wrote: Is there any way to get the maven build process to include a set of jars when compiling/packaging that are not in the repository? I have some vendor jars and I don't fancy packing them all up and placing them into the repository - I just want to point maven at a lib directory? Ideally you want to host for yourself a project wide maven repository, both to place your released artifacts into, and place the third party vendor jars into. This guarantees that someone other than you can build the code, without encountering an error or complaints about missing jars. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Not happy with maven
Martin von Gagern wrote: On the whole, I spent way too much time tweaking Maven, time I'd rather spend working on my project code. One of the most fundamental things about maven that you need to do to have a pleasant user experience, is to submit to maven. In other words, you shouldn't spend time tweaking maven, you should rather spend time tweaking your project to work using the standard way maven works. This is a big ask for many people I know, people come to maven going "but I want it to work like this, and maven won't let me". Standardisation means that if you follow the standards, there is a whole class of problems that are already solved. If your code is in a standard place, you no longer need to tell anybody, whether a computer or a human, where your code is, they already know. If your release procedures are standardised, you no longer need to tell anybody, whether a computer or a human, how to release your code or where it lives, they already know. Standardisation however doesn't help you if you want to invent your own standard. If you invent your own standard, you have to write the code yourself, and for me personally, rewriting your own standard is a waste of time and money. > I now decided to abandon maven, at > least for my end user applications. I'm not sure what I'll be using > instead. Maybe some form of ant, with or without ivy, with or without > build files generated from xslt. So you replace an exercise in messing around with maven with an exercise in messing around with ant. I don't see how that will help you focus on development. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Multiple project dependencies
[EMAIL PROTECTED] wrote: My question surrounds dependencies, and while I understand how to declare a dependency, what I want to know is how I make maven recompile dependencies. So if A depends on B, and I run 'mvn jar' in project B, how can I make it recompile (and I guess, run 'mvn install') in A? My scenerio is that I will be making changes to both A and B, but both are separate projects and I don't want to have to run 'mvn install' in A before doing anything with project B. Obviously, if A depends on B, A will not compile if B has been modified in some way given A fetches A.jar from the repository. Neither A or B share a common parent. In fact, they could easily have different parents. Having read and reread this, my gut feeling is that you're potentially trying to make a simple problem into a complicated one. If A depends on B, and you want to B to trigger stuff happening in A, that sounds like a classic circular dependency problem, which is broken regardless of what build strategy you use. Can you describe in more detail what problem you are trying solve? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: General Maven questions....
Taub, Jonathan wrote: I am well aware that some of the things I want to do go against Maven. However, all is based on personal experience and I don't consider Maven to be > a magic pill. My experience has shown me that too many people rely on > technology and automation to solve everything rather than to add some > proper engineering discipline, process, ability to think out of the box, > and sometime, manual steps. Discipline is the key word, however in order to properly understand discipline, you need to understand people. People will always choose the easiest path *for them*. People will build the binary from their arbitrarily modified and unrepeatable working copy, because it is the easiest thing for them to do. Given the choice between "update the documentation to reflect the new release" and "do nothing", the people will choose "do nothing". Maven has, in the release plugin, come up with a path that it easier to do correctly than it is to do incorrectly. All you need to do is to ensure the pom.xml file is correctly configured. Your release manager then just runs "mvn release:prepare release:perform", and it just works. Adding manual steps does not demonstrate discipline, instead it demonstrates reasons where your build can go wrong. Remember the end result of all of this: it is 3am, your troubleshooter has a production problem, they need to reproduce the problem in their development environment. 3am is not the time to discover that you have "application.jar" and don't know where the source code is. 3am is not the time to discover that the version in source control, wasn't actually the version used to build the binary, and the version in source control doesn't build. Your entire process should revolve around making your troubleshooter's lives easier, and that happens when you make disciplined development the path of least resistance. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Multiple project dependencies
[EMAIL PROTECTED] wrote:
I'm new to maven and I have a question regarding multiple projects and
how the can be linked. I've created a "common code" project, and I
have another which depends upon this project. I've got two
directories, two pom files, etc., and the common code project can
generate a jar file (mvn jar:jar). The other project has a dependency
in the pom.xml file:
com.x.common
x.common
0.0.1-SNAPSHOT
When the mvn process runs, it contacts the repositories and tries to
download this dependency, which will obviously fail. How do I
configure mvn to look locally for a dependency, and in this case, run
mvn jar:jar in the common project directory to obtain the required
jar?
It depends on how you want to structure your code.
If the common code is likely to follow it's own release cycle, make a
formal release of the common code, and then make your code depend on
that formal release. Don't do this manually, use the release plugin to
do this for you.
If the common code is likely to change alongside the other code, you
might choose to build and release all the jars together in one go.
What you want to do is create a multi-module project by creating a
parent pom project, and add each of the multi modules as children of
this parent, using the element in the pom. In each child
project, add the tag pointing back to the parent pom.
When you build the parent, all the modules listed within the parent will
be built.
If your dependencies are configured correctly, maven will figure out for
itself what order things should be built in.
Hint: in your children projects, make them inherit the parent's version
by putting in ${pom.version} as a variable. For example:
com.x.common
x.common
${pom.version}
When you release the parent, the children will be released and versioned
automatically.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Re: General Maven questions....
Taub, Jonathan wrote: I understand your concern. However, the application itself is self contained and is not meant to be a third party > application/library. Each release is tagged in Subversion, proper release notes are > maintained, and the application will contain a web page specifying the current > build/version. It makes no difference - when you have a problem, your troubleshooter will hold in their hands the deployed binary. And while they might think they are holding version X, but they're actually holding version Y because someone "forgot" to update the docs, and they waste hours trying to figure out where the confusion lies. From bitter bitter experience, don't even consider it. Or, if you do, don't be surprised if a troubleshooter chases you down with a rolling pin. Right now, changing multiple pom files each time before a release is a headache (and > then changing it back to snapshot). Which is why you don't do it, you use your computer and the maven-release-plugin to do it for you. The release plugin will let you release single jars at a time, or it will happily let you release a multi pom project. The release plugin will run your tests, check that your code is checked in properly, change the version numbers to the released version, check in the release version numbers, tag the new version, bump the released version again back to snapshot, commit the new version numbers, check out a pristine copy of your new release, build the release, build the documentation for the release, upload the released code to your maven repository, and upload the documentation to your documentation website, and the commands to do all this are as follows: mvn release:prepare release:perform And that's it. And if it bombs out half way through, just run the goals again and maven will continue where it left off. If you change your mind and want to rather roll back to how you started, you do this: mvn release:rollback Masochist (n): person who releases code manually without the release plugin. Regardless of how one sets an identifier of some sort for a release > number, it is going to be manual (unless one goes only by build number). I have done my share of deployments and tracking versions and find this > way to be the best. I also believe in checking final binary into a > versioning control system as the ONLY %100 sure way of knowing whether > a build can be reproduced is by checking the final product of the build > (one of the reasons I want to strip Maven files from artifacts). This is a myth. If you check your binary in, what do you have? A binary. Where did it come from? No way to tell. Did someone make a mistake and check the binary into the wrong place? No way to tell without explicitly picking apart evidence. If you want repeatability, remove the human being from the equation entirely. Make sure the version number is tagged on to absolutely everything, and smack any human who tries to manually fiddle with the version number with a rolled up newspaper. Computers are repeatable, humans are not. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: General Maven questions....
Taub, Jonathan wrote: Recently, I decided to introduce some changes into the build process and I was unable to figure out the following: * I want to have the final artifact name (.jar, .war, etc) WITHOUT the version number. The application/libraries are not meant to be a third party and version numbers (XXX-snapshot, XXX-1.5) are not needed and I want to have the same name each time regardless of the version. How do I accomplish this? I seriously and strongly recommend that you *don't* do this. The price of doing this is that you no longer know what version of your software you are looking at. Production is giving problems, you need to check out the source code, quick. Which tag do you check out? You have no idea. I have watched people using tools like Beyond Compare to painstakingly check whether one jar was the same as another one, just because the jar had no identifying marks on it. Save yourself the pain and the suffering: don't do it. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Dependencies not available in the future
David Ojeda wrote: So my question is: what can I do if I want to deliver give the source code and the dependencies jars? Here are some of my ideas: - Maintain a private repository with dependencies and use the deploy:deploy- file goal to add dependencies to it. Problem: in the love/hate relationship of client/developer companies, I think that the clients might argue that they do not want to depend on the developer company repository. Could be a repository in the client company. - Deliver all jars and scripts to install them in the local repository. Seems very 'hackish' and not so 'mavenish'. What is your experience with this situation? Keep it simple: Deliver a copy of the local repository (stored in ~/.m2/repository) along with the source code. Job done. In the worst case scenario where dependencies are missing, you just drop the saved repository into ~/.m2/repository, and build. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Can someone please explain release:rollback?
Borut Bolčina wrote: Thanks, but I would like the *exact" steps which occur by mvn release:rollback. It undoes everything from the point you ran release:prepare, until the point it failed. If you want the exact steps, run release:perform, and read the resulting output backwards. The normal behaviour of release:perform is to try and carry on from the point at which it failed. If you as the release manager decide that you want to abort the release entirely and try again some other time, you run release:rollback to undo all changes made so far. That's all there is to it, really. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Can someone please explain release:rollback?
Borut Bolčina wrote: there are examples and what happens during release:prepare and release:perform, but there is nothing about release:rollback at http://maven.apache.org/plugins/maven-release-plugin/ and in the 0.17 book. Can someone explain the behaviour of this goal? In what scenarios are you using it, if at all? If you get half way through release:prepare, and something breaks for some reason, and you want to abandon the attempt at release to fix it, you need to restore the various poms to their original state, and that in itself can be painful and error prone. release:rollback allows you to reinstate the original pom files and version numbers so you can try again. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Could anyone give me some idea what is the difference bwteen ant and maven?
dr2238 wrote: I have knowledge on ant, but doesn't have any knowledge on maven. I heard other say ant is kind of procedural language , while maven is an objected oriented language. Is that true? Could anyone explain it to me a little bit?It would be great if you can show me some small examples to let me understand what is the difference between them. They are very different from one another. Ant is effectively a scripting language: you give ant a sequence of tasks to do, and ant will go off and do those tasks for you. Like any scripting language, ant is entirely useless without a script to run (aka the build.xml file). And the ant script has to be written by you: ant isn't going to do anything unless you tell ant how to do it. Way back when, people realised that people were writing the same ant scripts, doing very similar things, over and over again, resulting in incompatible and incomplete behaviour. Surely if someone wrote just one ant script, and everyone used the same script, life would be much easier for everybody. In fact, life would be even easier if we could write the script in java directly and release it like we do any other java code. And so maven was born. Maven is not a scripting language. Maven is not a language at all. Maven is like a butler: it knows how to do stuff. "Maven, build my jar file and run the tests." "Certainly sir." Of course, in order to do useful stuff for you, maven needs to know a few details about your project. Before it can build your jar file, it needs to know your project's name and the current version so that it can give your jar file a sensible name. This is where pom.xml comes in. The POM is the place where everything maven needs to know is stored. The more information you add to your POM file, the more maven can do for you, without expecting you to tell maven how to do it, like you have to do with ant. If you tell maven what jars your project depends on, maven can automatically download those jars for you. When your project depends on 50 jars, that is one serious timesaver, and 50 less things you have to care about. Tell maven what kind of test library you use, and maven can run your tests for you as part of the build (mvn test). If you tell maven that you use eclipse, maven can set up your eclipse environment for you. Getting up and running in your IDE becomes a single simple command, instead of 45 minutes of clicking the mouse (mvn eclipse:eclipse). You can ask maven to build your javadocs for you. You already told maven where your source was, so maven has everything it needs to build the javadocs, without you having to tell it how (mvn javadoc). In fact, maven knows how to build lots of different kinds of autogenerated documentation, and package them together into an autogenerated website for you with helpful menu navigation (mvn site). And if you tell maven where the documentation should be uploaded to, maven can upload your site to your documentation webserver automatically (mvn site:deploy). At this point you're probably wondering how you will remember all these different maven commands when the time comes to tag a release of your code. Surely there must be a simple way for maven to sanity check your code to check whether it is properly checked in, test that your test suite runs correctly, tag your release, bump up the version numbers on all the files in source control to the next version number, check out a pristine copy of your tag, build the code, deploy the code to your release repository, build the documentation, upload the documentation for your release to your documentation website, all in one easy and pain free step? There is: mvn release:prepare release:perform That's it. Seriously. You might start wondering what would happen if you had to tell maven about each and every detail about your project: wouldn't it get out of hand? Of course it would, which is why maven introduces the concept of sensible defaults. Some information, like the project name, is mandatory. But other information, like where your source code lives, has a sensible default. Put your source code where maven expects to find it (src/main/java) and you no longer have to tell maven where your source code is, maven already knows. And if maven already knows where your source code is, then your fellow developers know where your source code is, without them having to look it up. By sticking to the maven standard way of laying out your project, there is lots of information that you no longer need to tell maven about, or your fellow developers about. That means less work, less confusion, and less documentation. You have just downloaded a project you have never seen before in your life. The project builds using maven. That means "mvn install" will build and install your code. You didn't need to read any documentation or instructions, you already knew how to build the
Re: Advice on dealing with hostility to Maven 2
Rusty Wright wrote: I completely agree. I'd go one step further with your building it on another machine and say that it has to build on another machine that's a different platform. I.e., if you're building on unix it must also build on Windows, or vice versa. And if you're building it in eclipse with the maven plugin it must also build outside of eclipse from the command line. An effective way of doing this is to actively make your CI server as different as humanly possible to your development environment. Different OS, different timezone. The more different you make it, the more likely you are to find latent defects, like hard coded paths, or failures due to sloppy timezone handling. In your CI environment you want to active give your code every possible reason to fail, because if the code succeeds despite this, your code very probably works bug free. Developers tend to be resistant to this: "Oh, it's Linux, that's why the test case fails", which is why this may need a bit of gentle (or not so gentle) discipline to enforce. In the example I am referring to, calculations that were failing "because of a different OS" were actually failing because of bad timezone handling, and people were resistant to fixing it. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Advice on dealing with hostility to Maven 2
[EMAIL PROTECTED] wrote: My approach on this was to sidestep the entire development team and go above them to the management team and sold them on the reporting capabilities instead of how simple the build becomes. I took an existing ant build based project and created a copy of it that was built with Maven. Once I had the basic mavenized build, I added Cobertura, Checkstyle, PMD, FindBugs, SureFire, TagList, JDepend, XRef and Dashboard reports and added a simple site.xml and a couple of simple APT based pages. Once I had that all working exactly the way I wanted, I showed each of the development managers (one at a time) the Dashboard report and showed them how they could drill down into the individual reports and see highlighted source code that showed where the code was not being tested or was violating one or more of the coding standards/guidelines. They were sufficiently impressed that things started to move forward. Once I had the managers on board, I knew it was a done deal... but I also knew I had to sell it to the naysayers in development. I showed them exactly the same dashboard report and showed them the POM and how easy it was to set up the reporting. Once they saw this, it was a pretty easy sell. Another blow-them-away plugin is the release plugin. Set up a proper mavenised project as above, and make sure that the release process properly tags your code, uploads your artifacts, and uploads your documentation. Arrange a demo where you run the command "mvn release:prepare release:perform", sit back, and show them what has been achieved. Show them the tag in source control, show them the artifact in the repository, show them the documentation. The release plugin sells maven, IMHO. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Advice on dealing with hostility to Maven 2
Rusty Wright wrote: The other experience that I've had is that some people are simply resistant to change. If your colleague is like that my suggestion would be, if you can afford to, is to become The Maven Guy and offer to set up his builds for him; in other words, write his pom.xml files. Do it in parallel with whatever he's using now and then demonstrate to him and the rest of your colleagues how much better it is. Like the old saying goes, you'll draw more flies with honey than you will with vinegar. In my experience, some people on projects believe that if it works for them, then everything is fine. In practice, the build often works for them, but doesn't work for anybody else, and they don't care. What works in this kind of environment is a general rule that says this: "Your work is not done until it can be shown to build and run cleanly on a second machine other than your own". Being the "maven guy" also works very well, especially if you are also the continuous integration guy, and the CI server is the "second machine" above. In many cases resistance to change comes about simply because people are too busy to stop and "sharpen the saw". Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Advice on dealing with hostility to Maven 2
cvr wrote: His arguments have been: - "The build system should be more complicated (harder to run, harder to configure) than the software" - "Why all this configuration for a glorified WGET?" - "Why do you need a shared repository (~/.m2/repository)? Disk space is really cheap" - "What’s wrong with just checking the jars in to source control under lib" - "I just have a build script that I run to compile my project, what's so hard about that?" (ed. note: it's a bash script) Having struggled with projects that had *no* build script (from the README: "step 1: open up Eclipse and click compile"), projects with undocumented dependencies (yay, ClassNotFoundException at runtime), and having fought multi-module ant builds for two years - Maven has worked out wonderfully. However, I can't seem to get this across. His mind is (angrily) closed. I'm just wondering if others on this forum have encountered similar hostility and you coped with it. I have encountered some shockingly broken build systems out there, but in all cases people recognised they were broken, and were grateful when it was fixed for them. Unfortunately I suspect that your colleague lacks experience with building projects any larger than trivial, and the only solution is to work around them until they gain enough experience to "get it". Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: trunk/tags/branches: root vs. project level
Hilco Wijbenga wrote: You shouldn't create multiple repositories without *very* good reasons. Multiple repositories just means having to duplicate authentication, backup setup, etcetera. Moreover, any kind of copying between projects is much harder that way. If you are working on multiple projects you'll eventually run into refactoring cases where you want multiple projects to reuse some shared code. That's a no-brainer in one repository but all but impossible (i.e. without losing history) in multiple repositories. And what do you gain? There's little advantage to having a repository per project. One of the key advantages of having one repository per project is the ability to take a particular project offline and archive it at some point in the future. This is important in setups where disk space use is likely to be significant over time, such as when working with graphics within a project, or other binary data that cannot be efficiently stored as diffs. This can also be important where disk space is at a premium, such as when disk space is hosted by a third party. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: no main or test directories created when using webapp archetype?
Rick wrote: (Now if Eclipse supported multi-modules better I wouldn't' mind as much. I wish there was a way I could have a project in eclipse represented by the parent pom and then have all the sub modules beneath it. Back when I used IDEA, I think this was possible. Does NetBeans maybe support this?) Eclipse does support multi-modules, use it all the time. Make sure that your eclipse config is generated by the maven-eclipse-plugin to do this the easy way. Each module of a multi-module project will be added as a project dependency (instead of a jar dependency) in eclipse. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: improve Maven performance
Yann wrote: In our company lot of people complains that our maven 2 builds are too long. We use multi modules and most of the time we only need to build 1 or 2 modules not all of them. The ideal longer term solution is to break the project up into smaller sections, either individual artifacts with their own life cycle, or small multi module builds. Try and separate out code that tends to change often, and code that does not, and then put the code that doesn't change often into its own release cycle. You will also find you will have less problems this way, because each release is a release of less code, and therefore there is less opportunity for stuff to go wrong. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
Rick wrote: Here's what I'm confused at though. Project A builds a jar. It needs to be used in Project B. Ideally of course Project A should be tested in Project B locally, but in reality (unfortunately) the dev environment often becomes a more 'real' test. Typically the developers of Project A will have access to Project B, so can't they just set up the dev profile of Project B, to use the latest stable version? This way they won't have to constantly be changing the profile for Project B.. or is that a bad practice? Assuming some time goes by while they do more 'real life' stuff in dev and they like how things are. They could then change the version of the dependency of Project A to a set number and then check that updated pom/profile into version control. This is up to you. The core thing to understand is snapshots equals "all bets are off". If project B wants to live on the bleeding edge of project A, and early on in development this is likely, project B is free to depend on snapshots of project A. But by doing this, project B is saying "we accept that project A may break at any time, and we accept this". Over time, when development starts to settle down, project B will start wanting stability and a goalpost that doesn't move. At that point, project B will start depending on releases of project A. There is no "right" answer as to when this should happen, this is up to the development team. But it is down to a binary choice: be on the snapshot bleeding edge and access changes quickly and accept that it will break randomly and without warning, or depend on a release, and you get stability and controlled change. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
Dave Newton wrote: In other words, use the maven-release-plugin to publish formal releases of code, and make sure that project A never depends on a snapshot of project B if you can possibly avoid it. Use proper version numbers. Would it be reasonable to say that *released* versions of A shouldn't depend on B-snapshots? Yes - the release plugin will enforce this for you. The release plugin will refuse to continue with a release if any component of that release is a snapshot. This is because, by definition, if one of the components in a snapshot, then all bets are off for the entire release. A reminder of why this matters: It's 3am, your production server shows a bug. You want to rebuild the code on your dev environment so that you can recreate the bug, and fix it. But your build depends on a snapshot, so when you rebuild the code, you don't end up with the same code as the code in production. As a result, you cannot reproduce the bug, and your troubleshooter climbs the clock tower with a rifle. Then, after coaxing your troubleshooter down from the clock tower, they stumble on the fix, and they attempt to put a fixed version of the code back into production. But again, you could not repeat your build, so you cannot put your fix - and *only* your fix - into production, so you now have new bugs. Your troubleshooter goes back up the clock tower. If you get your developers to respect the release plugin, the side effect is that troubleshooting becomes an order of magnitude easier. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
Rick wrote: Is it common for the development environment to rely on company snapshot versions and only in test or later, to define specific version numbers? I seem weary though to have for example project B rely on the snapshot version of project A. Maybe project A is working on a release that won't break project B, but it's still a release that project B wouldn't necessarily want (especially if they haven't been communicating with each other. For example maybe project A is changing the way a calculation is done, but project B still wants the calc to stay the old way for now. If they are relying on snapshots, they might not be aware that the change was even made.) You are describing a recipe for disaster - use proper release management, and you will be fine. In other words, use the maven-release-plugin to publish formal releases of code, and make sure that project A never depends on a snapshot of project B if you can possibly avoid it. Use proper version numbers. "snapshot" is another way of saying "all bets are off", and I cannot stress this enough: if project B depends on snapshots from project A, project B is saying "we accept that our code will break with no warning and for no clear reason because of project A, and it will be our own fault". Get your projects to release often, and you will minimise the need for people to depend on snapshots. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: what to do when you require a dependency in an open-source project that isn't available on a public maven 2 repository, but could be (and you can't host it)
Gary Weaver wrote: Are there any of you out there that have open-source projects where you couldn't find a dependency in a public Maven 2 repo, and if you, how did you handle it? We run our own maven repository where we publish our own artifacts released using the release plugin. Jars that are not publicly available, or jars that we have patched ourselves, go into this same repository. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: What is current status of repositorytools-plugin ?
Arnaud Bailly wrote: I am investigating how to create "reproducible" builds with maven2. There is a proposal from Brett Porter in the wiki about refactoring local repository structure that goes in that direction. Not sure however when it will be available. Enforcers and requirements also helps, as well as of course pinning plugin versions. I was however hoping to find a way to "tag" the local repository used for a build in order to be able to reproduce the latter and/or to compare local repositories produced by two builds that are supposed to be identical. A fundamental rule underlying maven is that once an artifact is rolled, it never changes. You cannot have repeatability without this. If your local or remote repository is changing over time, then something is very broken. And it is surprisingly easy unfortunately to get bitten by this: the person doing the release forgets to include vital file X in their build, so rather than rerolling the release, they cheat and manually insert missing file X into their released jar file without telling anybody. Fast forward a short while, and person Y has checked out the source for that release - minus file X - to investigate a production problem, and they get the error "file X is missing". Much time is wasted trying to investigate why they are suddenly getting the error about a missing file X, instead of the production problem they are trying to solve. This is caused because the source doesn't match the binary, it is not repeatable. A possible solution to your problem could be hosting your local repository (which I am interpreting to mean the repository local to your organisation where you deploy your releases) on a subversion server over WebDAV. Subversion has a very useful feature in that a repository is accessible via a normal web browser (which means maven can download artifacts without maven having any knowledge whatsoever that it is really talking to subversion). It has a second even more useful feature giving write access to the repository via WebDAV (which means the maven release process can deploy the new artifacts to the WebDAV maven repository, again without any knowledge whatsoever that subversion is even there). Because your maven repository is now also a subversion repository, you now have full history of who did what. If an artifact is changed, that can be searched for in the subversion history and red flagged before that jar makes it into production. And the subversion repository will have full details of exactly who overwrote the binary, and when. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: creating runnable jar file
cablepuff wrote: however i get this error about namespace www.springframework.org/schema/tx cannot be found. Is their a better way to create deployable jar files that runs on different machine. It sounds like you are trying to create an uberjar, AKA a jar-with-dependencies. An uberjar is a new big jar created by unpacking all the dependent jars into one big jar, which being self contained, will run on any machine without needing any special classpath setup. The assembly plugin can create uberjars for you, look at the docs for the assembly plugin to see how. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: System Scope
CORUM, M E [AG/1000] wrote: I assume that you would be replacing that with some equivalent functionality, right? Otherwise, you would be taking away the capability for large companies to use Maven. Let me give an example (actually two). We have jar files from vendors that our Maven projects must depend on. In one case, there is a licensing agreement that disallows us from putting these jars into Maven/Nexus. In another case, the jar is "security-sensitive" and must not be put in Maven due to audit or security requirements. The company I work at has over 200 Maven projects now. Taking out system scope would immediately cause us to have to look for an alternative to Maven due to legal, audit, and security requirements. System scope (or an equivalent capability) must stay in Maven for it to be used by many companies. Or you could just patch maven to put the feature back ;) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: How do I override a plugin dependency?
Brian Fox wrote: Hi, I blogged about this with examples. I can't copy and paste on the iPhone but you can find it at http://blogs.Sonatype.com/brian I discovered a number of blogs explaining how to do it, but none of them worked. After some testing it turned out that if you tried to override a direct plugin dependency it worked, but if you tried to override a transitive dependency (as is the case here) it didn't work. http://jira.codehaus.org/browse/MNG-3725 Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Having trouble with Maven release plugin using SubVersion
Ken Tanaka wrote: Before issuing the 'mvn release:prepare' command, an 'svn update' on the parent directory of the directory renamed (or at the top level) will update the SubVersion metadata. The update command doesn't print anything so it appears like it doesn't do anything, but it's required nonetheless. Would there be any harm in having the release plugin perform an 'svn update' at the start of the release:prepare goal? I have run into problems in the past with the release plugin and working copies that were fully checked in, but not up to date. I would argue that the equivalent of an "svn update" is performed by the release plugin when the check is made whether everything is checked in. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
How do I override a plugin dependency?
Hi all, I have a need to override a specific dependency used by the maven-torque-plugin, and I am struggling to convince maven v2.0.9 to do this. The symptoms are that the original jar is being used, instead of the overridden jar, which is effectively ignored. To test this, I have deleted the original jar completely from my local maven repository, and what I expect to happen is that maven should not try to download this dependency again, because it has been overridden. In practise, maven downloads the original jar, and ignores the overridden jar. Is there anything obvious that I have missed in this process? My plugin definition looks like this: org.apache.torque torque-maven-plugin 3.3 org.apache.derby derby 10.4.1.3 org.apache.torque torque-templates 3.3.1 Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
