We use a tool like Beyond Compare to analyze locally made EARs to those from
the CI system early in our engagement to ensure we have faithfully reproduced
what the customer asked for. Any difference we find we make adjustment for in
Maven.
Curt Yanko |
While not complete, the Sonar tool provides two-way lookup and their
public Nemo instance has a lot of the biggest OSS libraries in it.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 700 times a day
We find that a Site report produces a better BOM. The POM, even the
*effective* one, often does not list all of the dependencies. We also
like Sonar for two-way traceability of dependencies.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
You'll want to look into version ranges, but be warned, they can be evil
and affect reproducibility.
Just working against a SNAPSHOT keeps you up-to-date on internal stuff.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen,
We'd handle this in our CI system by running two jobs in parallel
coupled to different tooling.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
-Original Message-
From:
Another item on my list of why the Release Plugin is evil.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
-Original Message-
From: Claves Do Amaral
We would manage this in our CI server and indeed control what JAVA_HOME
is set to for different workflows. We'd further use Maven profiles to
toggle the setting within Maven for things like compiler settings. Then
one code change could trigger two builds in parallel targeting different
JDK's.
Not familiar with Archiva but I do know that the Nexus Pro product has a
feature set geared at this use case. Don't recall if it is just the use
of meta-data or what but you can proxy stuff openly but then *promote*
things to a Definitive Software Library status and run authoritative
builds
Folder structure is one Maven battle we haven't had to fight very much and we
do a lot of Ant conversions. If the original structure is reasonable overriding
the Maven defaults usually is enough.
Curt Yanko | Continuous Integration Services | UnitedHealth Group
Todd,
You are of course correct. Sometimes it takes a more incremental
approach. We start with Build Best Practices:
Establish Release Authority
Establish Reproducibility
Automate Processes
Abstract Process and Metadata from the physical resource
Optimize Process and supporting architecture
Google around, there are some recent articles about this using stuff
like Failsafe and hooking into the Verify phase of the build lifecycle
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a
Can you use a tool like Beyond Compare to compare the two WAR files?
That should identify the difference and point you to what needs to be
configured in Maven.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a
This might be a good place to try Sonar along with the Build Breaker
plugin.
Curt Yanko
-Original Message-
From: eyal edri [mailto:eyal.e...@gmail.com]
Sent: Thursday, April 28, 2011 8:39 AM
To: Maven Users List
Subject: Making findbugs:check
We set up *sequencing* in our CI tool.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
-Original Message-
From: Igor Petruk [mailto:igor_pet...@epam.com]
Sent: Friday,
I'm sure it can or cannot be done but I do know we avoid that and
maintain one local per version of Maven we support on each build agent.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
that
is already available as a goal.
I welcome any and all feedback.
Eric Pabst
Yanko, Curtis wrote:
I though the idea we talked about was to re-write the POM
that get's
packaged with the actual version used from a version range?
Curt Yanko
This is what Build Management Servers can do for you. It could poll each
project each morning and only build the ones that have changes.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
Yes, I suppose I could do that (which is pretty much what I
did before), but it sort of defeats the whole purpose of what
I'm trying to accomplish here, which is, be a little more
organized about what is release and what is in development.
Then break up your builds so each one build
A not working build doesn't sound simpler to me.
We only use aggregation builds for local builds but our CI just builds
the changed module and then triggers dependent modules up the
architectural chain.
Curt Yanko | Continuous Integration Services | UnitedHealth
We use our build management system for these items. We read a version number
out of the POM to create a fully qualified version in the BMS and then pass
that back into Maven for inclusion in manifest and such.
Labeling is definitely the responsibility of the BMS too.
Sounds like a job for the build management system itself. In Anthill we
can tell job steps to run if the previous step failed.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
An area we've been successful with in using profiles is to distinguish
between local builds and CI build to toggle Fat v Skinny WARs
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
We use Sonar and it's Library look up mechanism to do *impact analysis*
if that's what you mean by reverse dependency.
From a build standpoint AnthillPro support both Push and Pull style
dependency triggers. Since we are a CI shop we use Push to trigger the
build of the item(s) that use what we
Is there some compelling reason why these files are created outside of
*target*? The idea of *target* is to be home to all artifacts of the
build process.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a
How is this an override? You have declared two different things
(different artifactId). But... This is why we don't declare dependencies
in Parent POMs ( I see someone else beat me to the Super POM
clarification).
We only declare dependencies as dependencyManagement items in our
Parent POMs and
Yes, we treat POMs as projects and they are in our CI system so any
changes committed to SVN trigger a build which deploys the POM.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
It *always* looks up a level for a pom. This is why I would only use
that *up-a-level* pom for aggregation and not inheritance stuff. For
that we make the parentpom project at the module level and *build* it
(install or deploy) like any other project.
Curt Yanko
I found this article to be very helpful
http://olex.openlogic.com/wazi/2010/creating-intelligent-projects-with-m
aven/
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
-Original
I though the idea we talked about was to re-write the POM that get's
packaged with the actual version used from a version range?
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
The Assembly plugin can have multiple assemblies defined.
We produce one distribution with ALL configs in it though.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
-Original
You're happy about NOT using CI
-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: Saturday, November 13, 2010 2:05 PM
To: users@maven.apache.org
Subject: Re: Continuous Delivery and Maven
I would add the following bits of reality.
We don't
[mailto:rwhee...@artifact-software.com]
Sent: Monday, November 15, 2010 10:28 AM
To: users@maven.apache.org
Subject: Re: Continuous Delivery and Maven
On 15/11/2010 8:18 AM, Yanko, Curtis wrote:
You're happy about NOT using CI
Yes. It seems to be a tool that is prone to being used foolishly
to reproduce your problem.
Vincent
2010/11/11 Yanko, Curtis curt_ya...@uhc.com
Very odd indeed, we use properties quite pervasively and I haven't
seen this.
I do recall some chicken-n-egg scenarios but this doesn't
to fit that mold.
-Original Message-
From: chemit
We use Windows in some places and I have never run into this and yes, we
use lots of properties and inheritance.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
-Original
Is this only on Maven 3.0? We haven't crossed that bridge yet.
-Original Message-
From: chemit
Hi guys,
I was testing some of my mojo on windows platform (xp) and
how surprised I was to see there is some big problems.
I had some
[ERROR]
@maven.apache.org
Subject: Re: properties inheritance does not work on windows os
On Thu, 11 Nov 2010 08:27:24 -0600
Yanko, Curtis curt_ya...@uhc.com wrote:
Is this only on Maven 3.0? We haven't crossed that bridge yet.
Good point, I have just try with version 2.2.1 and result is the same.
I
The dep ranges make more sense to me because they can equate to
feature/functionality sets and still enable parallel development for all
those non-CD shops ;-) I'm sure there is no notion of parallel
development in CD since they eschew branches in favor of Bliki feature
toggles (which are
Obviously there are times when that is the case but and others when the
boundary would be welcome.
-Original Message-
From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com]
Sent: Wednesday, November 10, 2010 2:54 PM
To: Maven Users List
Subject: RE: Continuous Delivery and Maven
I
+1
-Original Message-
From: Brian Topping [mailto:topp...@codehaus.org]
Sent: Wednesday, November 10, 2010 3:49 PM
To: Maven Users List
Subject: Re: Figuring out the proper Maven dependency setting
On Nov 10, 2010, at 3:40 PM, marshall wrote:
Hi;
This is probably a
I would agree with you on this one. I think one of the discussions that
is missing here is the idea of when or how we determine we have
*something of value*.
My assumptions is it goes something like this:
Build - Inspect and Test - Value? YES|NO
Right now the approach presented in this group
I would be curious if you could unpack you app and just replace the JARs
with ones from Maven repo's and have it still work.
I can't tell you how projects I've encountered where I cannot figure
what version a JAR is or where it came from. I am sure I have seen hand
modified JAR lumping packages
challenge.
-Original Message-
From: Brian Topping [mailto:topp...@codehaus.org]
Sent: Wednesday, November 10, 2010 4:25 PM
To: Maven Users List
Subject: Re: Figuring out the proper Maven dependency setting
On Nov 10, 2010, at 4:06 PM, Yanko, Curtis wrote:
I have used
+1, That's the spirit! It's like I said, many teams for a long time have
under-valued the build process and deem the whole activity to be not
worth their time. And yet, so few teams I meet can provided me with a
bill-of-materials or even a basic architectural drawing showing the
relationship of
This was precisely where I was headed.
I was thinking about using version ranges in depMgmnt and *burning lots
of versions in the CI process but having a release plugin that ID's the
version retrieved and re-wrote the POM to be version specific at package
time.
I'm drawn to the idea of using
What if you just avoid the check in? Only package the pom and deploy the jar?
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
-Original Message-
From: Stephen Connolly
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: Tuesday, November 09, 2010 11:05 AM
To: Maven Users List
Subject: Re: Continuous Delivery and Maven
Why bother... the checkin is automatic and actually a good thing IMHO
On 9 November 2010 15:37, Yanko
: Tuesday, November 09, 2010 4:10 PM
To: Maven Users List
Subject: Re: RE: Continuous Delivery and Maven
But if we do it my way, the tag has the resolved versions, while trunk
keeps the ranges... Best of all worlds ;-)
On 9 Nov 2010 16:21, Yanko, Curtis curt_ya...@uhc.com wrote:
Because I thought we
the repo, or the versions that were
originally fetched when it was run on the CI system?
Can I even find out exactly which versions from svn the snapshots of B
and C came from that were used by the CI system to generate the original
build of A?
Thanks,
Jez.
On 7 November 2010 20:10, Yanko, Curtis
I would agree. CD is the logicval extension of CI, Continuous
Inspection, Continuous Testing and then and only then, Continuous
Delivery.
So I whole heartedly agree, Jez seems to have an ad hoc dev proves as an
input to his CD process and despite that, Maven can still make it work.
I also
ad hoc dev *process* as an input...
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
-Original Message-
From: Yanko, Curtis
Sent: Monday, November 08, 2010 9:49 AM
To: Maven
I like where you are going with this but I don't understand the need to
re-build or to have two different build processes. I'm in the Maciej Zawadzki
camp of Build lives, that a build is just the beginning and you need to manage
it in a way that let you come back and continue to advance it if
You can turn on unique snapshots in your repo manager or, like us, set
all module versions from the parent POM.
To release, we update the version of the Parent POM and commit then do
it again to set it back to snapshot. So, all of *our* modules can be in
flux but any *external ones* (not managed
There are techniques to do that, stuff like feature toggle for instance.
The Agile Executive just ran a story on this recently.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
I didn't see a reply from a Brian. What answer did he provided that
answered your question?
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
-Original Message-
From: jhumble
]
Sent: Monday, November 08, 2010 12:11 PM
To: users@maven.apache.org
Subject: Re: Continuous Delivery and Maven
Hi Curt - it was this one:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3254439.html
On 8 November 2010 09:07, Yanko, Curtis [via Maven]
ml-node+3255382
purposes that we can trace
back from any given binary to the exact versions in version control that
it and all its build-time dependencies came from.
On 8 November 2010 09:34, Yanko, Curtis [via Maven]
ml-node+3255434-1467695194-143...@n5.nabble.comml-node%2B3255434-146769
ml-node+5194-143...@n5
and Maven
On Nov 8, 2010, at 12:33 PM, Yanko, Curtis wrote:
Why is that not guaranteed to exist or be reliable?
A Maven repository is a cache, not a reliable persistent store. *Yours*
may be reliable, but the artifacts that are built to it should not
contain metadata that, if lost, would make
I think our fundamental schism is that you see managing POM's as too
hard where as I see them as so easy and a no brainer when it comes to
ROI especially considering the alternatives.
We have plenty of initiatives that span system boundaries but those need
to be addressed in architecture and not
--And I think this is the nub of the problem - you don't have a
sufficiently frequent release cycle to experience the problems I am
describing.
I too came to this same conclusion. I get that now, even every two weeks
isn't enough but I still don't see my process being a pain even if we
released
I'm just saying, that as a practical matter, we can today solve your
problem without the need for a new plugin. Reproducible, and
Auditable.
I can look at anything directly, even in Prod, and make the leap all
the way to SVN without a single cross reference or lookup because we
put all
Very interesting discussion. With all due respect to Mr. Humble, and I
am a big fan of CD, I am going to venture to say that you don't
understand Maven very well. As a thought experiment, you are correct in
saying that a build based on snapshots is not reproducible. As a more
practical matter
+1 ;-)
I can't tell you how many times we get teams trying to turn Subversion
and the build process into a CMS
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
-Original
We've had the opposite experience with our large scale implementation.
We keep the release numbers in sync by only setting it in the Parent POM
so regardless of number of modules there is only one change to be made.
The purist in me want to version everything separately but it has proved
to be
I wanted to share this article which I found to be quite a useful, and
concise, guide to some Maven best practices.
The part on managing projects is how we've gone about it and in our
world where everything scales exposing any pain points, that idiom has
helped us simplify managing projects with
But in a CI system, the latest B is always built. In fact, in our Build
Management system we use push style dependencies instead of pull. So, instead
of a build of A seeing in B needs to be built, When B builds it tells A. In
this way, any change will ultimately trigger all of the dependent
We put deployment info in the Parent POM's but... We put the logon
credentials only in the settings.xml on the build servers. This way only
authoritative builds can be deployed to the corporate repo.
Curt Yanko | Continuous Integration Services | UnitedHealth
it will amount to a basically identical effective POM. The
issue at hand is still that I have no idea why Maven is trying to deploy
a SNAPSHOT to the release repo.
Thanks,
-martin
On Thu, Nov 4, 2010 at 2:11 PM, Yanko, Curtis curt_ya...@uhc.com
wrote:
We put deployment info in the Parent POM's
I'd only put the version in the ParentPOM in a depMgmnt section and
then declare dependencies without versions at all.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
-Original Message-
From:
Perhaps the enforcer plugin could help
http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
-Original Message-
From:
Try the dependency plugin
dependency:resolve-plugins
http://maven.apache.org/plugins/maven-dependency-plugin/resolve-plugins-
mojo.html
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
-Original
IT Happen, one build at a time
-Original Message-
From: Phillip Hellewell [mailto:ssh...@gmail.com]
Sent: Wednesday, October 20, 2010 6:51 PM
To: Maven Users List
Subject: Re: Plugin versions
On Wed, Oct 20, 2010 at 4:11 PM, Yanko, Curtis curt_ya...@uhc.com
wrote:
Try the dependency plugin
If the parent is deployed internally then you don't need to worry about
the structure.
Alternatively, if you are using a Build Management s Server like AHP or
Hudson, tey can alter the layout on-the-fly at checkout/update time.
Curt Yanko | Continuous
+1
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
-Original Message-
From: Brian Smith [mailto:bmjsm...@gmail.com]
Sent: Friday, October 15, 2010 5:39 AM
To: Maven Users List
Subject: Re:
Can anyone recommend a taglib plugin to generate TLD's?
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
This e-mail, including attachments, may include confidential and/or
proprietary information, and
To me, the answer is yes,yes, yes but then I don't see Maven as a
*programming* language.
To me I can quickly see what we are trying to do and what it needs to do
it.
In a world where Source + Tools = Product (where tools = tools +
libraries) I see documentation about the tools.
Using antrun is not Maven
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
-Original Message-
From: Kenneth McDonald [mailto:kenneth.m.mcdon...@sbcglobal.net]
Sent: Tuesday, October 12, 2010
They get packaged into the artifact itself. No need to commit
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
-Original Message-
From: paulus.benedic...@gmail.com
Look at the Maven SuperPOM (
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
#Super_POM ) since that is where the *defaults* come from.
In the start of the build section properties are set for where source
and test code is plus some other items. I put all of those, as-is
Each environment identifies itself and your app uses that info to
connect to the right properties at runtime.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
-Original Message-
From: Jon
We do. It is simply a requirement for the AppDev team to implement. So,
even when they forget, we catch it in the build process since those
builds happen on our servers where the settings.xml is definitely set to
use our internal repository.
Curt Yanko |
a former
build of the project.
Mario
Am 29.09.2010 15:11, schrieb Yanko, Curtis:
We use an idiom whereby we don't declare any version in the dependency
itself but use the depMgmnt section in a project level POM to *pin*
versions.
Curt Yanko | Continuous
? The only time you
really need to reproduce it is when something is broken and then what
you REALLY need is a simple mechanism for making a new determinable
release.
On Thursday 30 September 2010 02:27:32 Yanko, Curtis wrote:
I don't advocate version ranges at all since your build may not be
re
in this
forum: Avoid version ranges! (the post of Michael McCallum is an exception ;-)
) I am not sure if it's the maven way.
On the other hand: If you do the dependency management manually, you use Maven
just to download the artifacts. Is that the maven way?
Thanks,
Mario
Am 29.09.2010 15:27, schrieb Yanko
We use an idiom whereby we don't declare any version in the dependency
itself but use the depMgmnt section in a project level POM to *pin*
versions.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
This article completely changed the way we structure our POMs
http://olex.openlogic.com/wazi/2010/creating-intelligent-projects-with-m
aven/
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
I do find it surprising that your saying declaring a dependency is *only
a wish*? A declared dependency *should be* closest to the root, our do
you make your declarations in a Parent POM?
We too used to *factor up* any shared dep to the Parent but have stopped
since it creates a couple of
We separate all code scanning activities from *builds*. Our builds are
designed to fail fast by just doing the compile, unit test and
packaging. We run a secondary process, that we don't feel has the same
time constraint, to perform documentation and analysis.
I can't help but feel that you have completely obfuscated a relatively basic
need. It's like you have the right tools but the wrong implementation.
Why doesn't storing your artifacts in Nexus also along with Maven POMs to
specify the dependencies for each project work for you?
Site?
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
CT039-05C | office: 860.702.9059 | email: c...@uhc.com | intranet: cis.uhc.com
Making IT Happen, one build at a time
-Original Message-
From: Felipe Roos
Looks backwards to me. I put a version in the Parent and then don't list
on in the children at all, it get's inherited.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
-Original Message-
From:
http://maven.apache.org/plugins/maven-ear-plugin/examples/customizing-a-
module-filename.html
-Original Message-
From: D D [mailto:dawi...@gmail.com]
Sent: Friday, July 09, 2010 1:17 PM
To: Maven Users List
Subject: Naming EJB in an EAR
Hello,
I noticed that Maven created an ear for
You can set up maven in paralell, non-disruptively. Once you have that, get
site reports working and then ask the Ant guys to produce a bill-of-materials!
===
Curtis Yanko
UHGIT
Computer Services - ADIS
Continuous Integration Service
https://ulink.uhc.com/groups/cis
We avoid any snapshot or 'reanges' in our releases, everything is
versioned. We also generate the Site report with it's dependency report
which we find quite comprehensive. So from our point of view we haven't
had any issues with reproducibility as is.
We do also capture severy depency plugin
Is anyone having any luck with this plugin? It seems pretty broken to
me. I have scoured the web and can find little, if any documentation. It
also seems as if the guy at anydoby.com re-wrote the plugin to work?!
Here is what I have so far:
plugin
groupIdorg.codehaus.mojo/groupId
As we embark on this little endeavor I wanted to see if anyone had some
input or experience in this area. We use Artifactory as an internal repo
and are trying to support WAS 5.1 6 apps.
I found the Peter Pilgrim article (
Maven supports the idea of latest if you use version ranges no? So at
least for a given milestone you can grab the latest release of a given
component.
==
Curtis Yanko
Application Developer Infrastructure Services
Source-Build-Deploy
W: 860.702.9059
M: 860.881.2050
-Original
Anybody using Sonar? It's not clear to me how it works in conjunction
with something like Site or does it replace it?
==
Curtis Yanko
Application Developer Infrastructure Services
Source-Build-Deploy
This e-mail, including attachments, may include confidential and/or
proprietary
You would have to serialize these, so that your project calls, lets say
the Web one, as it's parent which in turn has the DB one as it's parent.
==
Curtis Yanko
Application Developer Infrastructure Services
Source-Build-Deploy
W: 860.702.9059
M: 860.881.2050
This e-mail, including
We also use our CI (or Build Management System) to do this. Although we
do 'push' style and not 'pull' dependencies). We're CI so I know we have
a latest good build already but I can trigger a 'dependent' to build if
it's 'dependency' has built successfully.
===
-Curt
W: 860.702.9059
M:
I can't speak to Hudson but it seems to me in AnthillPro we have a job
step after the build step that always runs to ensure any test get
published. So, even though the build failed we can still do other
things.
===
-Curt
W: 860.702.9059
M: 860.881.2050
-Original Message-
From: Carlos
1 - 100 of 102 matches
Mail list logo
