Hi Scott -
I'll start with "it depends".
I'll also point out that Stephen has pointed out an interesting plugin
below, but I didn't dig deeply into it.
You could also build your "shipping" system around the maven release plugin
that exists for jenkins (granting anyone who can click a button the ability
to run the release - that's likely possible regardless of route).
I'm personally in the camp where I firmly believe jenkins/maven shouldn't
be your orchestration tool. Another glimpse into my world, I use embedded
jetty and when maven builds, there are two options -
1 - An exploded "dir" type assembly (done via an assembly descriptor) - you
end up with a structure in your target directory where <appname>-<version>
has a bin/conf/war directory. Inside the "conf" dir, we have any
configuration files, bin has our init/start/stop script and war has our
war. The conf is placed in the target dir after being filtered (we use the
<properties> and settings.xml to override per dev machine - I'm not
enforcing where or what dev installs - just facilitating HOW the specify
these locations).
2 - A "bin" zip file (easiest way to share across platforms) - this is a
zip file with all the config and script files in a "templates" directory
instead. Any ${foo} values are replaced with their ERB equivalents because
we use chef to deploy. When chef deploys, it pulls this "bin" zip from
nexus, unpacks it, then bulk copies the config files just up one directory,
expanding any templates along the way. This is good because if dev adds a
new property file or script or some other thing, it's automagically
included in the "bin" zip and automagically managed by chef. This "bin"
zip is "attached" per the SOP maven way so at t end of any build or
release, it ends up in nexus. Additionally, for any job in jenkins, we
have a shared (shared between jenkins jobs) maven config which activates
the "prod" profile (there's slightly more to this, but that's beyond the
scope of this email). This allows us to build once and deploy anywhere.
Our build(s) are per-service - so we don't have some massive repo that has
all artifacts in it. All of our service builds take about 1 to 2 minutes,
so it's pretty cheap to roll out a new release (release small portions
frequently).
I've glossed over several details - not because of skeletons, but because
they could be several paragraphs and hours of conversation :-)
Again - if you need any details - feel free to reach out directly.
On Thu, Dec 27, 2012 at 6:05 PM, Scott Klein <[email protected]>wrote:
> > Don't repackage per env!!!!
>
> Could you expand on that concept a little bit for me.
>
> My question is whether you should run a "mvn deploy -P Test" to get your
> artifact(s) up to your Test environment, because that will re-package
> right? Or do you use some other way to take existing artifact(s) from your
> repo and push them out to the test server (or any server)?
>
> Based on your comment, I am assuming the latter but not sure how one could
> go about doing that...I guess I just assumed that the proper thing to do
> was use deploy for this, as I didn't see another option.
>
> Should I always deploy to my repo and then perform some separate task
> which takes artifacts from my repo and pushes them over to one of my app
> servers? If so, how the heck do I do that within Maven or, upon reflection,
> outside of Maven?
>
> Based on what I have read:
> "Maven's responsibility for building your artifact ends when it has
> delivered an environment independent artifact into the Maven Repository."
>
> ...and...
>
> "deploy - done in an integration or release environment, copies the final
> package to the remote repository for sharing with other developers and
> projects."
>
> It sounds like if you use Cargo (or similar) you would almost create a new
> Phase (or goal, or something) which would bypass all parent phases (so you
> don't repackage) and simply grab your artifact(s) from your repo and push
> them over. That seems a bit dramatic.
>
> I found this old article as an example of what I was considering:
>
> http://dpillay.wordpress.com/2009/04/12/maven-cargo-tomcat-auto-deployment/
>
> However, here he is making it part of the "install" phase which I don't
> think strictly adheres to the Maven lifecycle (install - install the
> package into the local repository, for use as a dependency in other
> projects locally) nor to your admonition. It sounds to me like Maven washes
> it hands of you once you place an artifact in the repo and everyone using
> Cargo to perform artifact pushes to their dev/test/prod environments is
> breaking the spirit of Maven. Therefore, I would have to rely on tools
> other than Maven to do this.
>
> Well, now I think I talked myself into the "external tool" camp ... argh!
>
>
> Thanks
> scott
>
> -----Original Message-----
> From: Maven User [mailto:[email protected]]
> Sent: Thursday, December 27, 2012 7:47 AM
> To: Maven Users List
> Subject: Re: Maven profiles and resource filtering
>
> AHHHH - yes, all your "configuration" should be OUTSIDE your war/ear/jar
> files!
>
> Don't repackage per env!!!! Also, don't force someone to unfurl your
> artifact, alter config, then re-roll it....
>
>
>
>
> On Wed, Dec 26, 2012 at 3:05 PM, Stephen Connolly <
> [email protected]> wrote:
>
> > When artifacts get installed into the remote repository or local
> > repository cache, you do not have information about what profiles were
> > active when the artifact was built. as a result, in multi-module
> > builds, if you are working in a sub-module, you can end up with mixed
> artifacts, etc.
> >
> > Plus when you do your release you need to ask what profiles were
> > active when the release was cut.
> >
> > It is a seductive idea... until you dig deep enough. The real way to
> > work is to have the configuration externalized so that you don't need
> > to rebuild to deploy to a different environment.
> >
> > -Stephen
> >
> >
> > On 26 December 2012 18:54, Niranjan Rao <[email protected]> wrote:
> >
> > > I read the blog entry and still confused about why we should not be
> > > using profiles. Perhaps I am just being dumb.
> > >
> > > As for our particular case, maven and resource filtering actually
> > > has
> > been
> > > very helpful to us. We have multiple locations where development
> > > happens, each location has its own setup of database/message queue
> > > and other external resources application needs. With the help of
> > > resource
> > filtering,
> > > we are able to set right options in the configuration files so that
> > > developers don't step on each other shoes. Each one gets his own
> > > "namespace" as far external resources are concerned. Every developer
> > > is required to execute the complete test suite in their own
> > > environment
> > before
> > > pushing their changes.
> > >
> > > There are couple profiles we use during hudson builds - one meant
> > > for CI, almost same as developer's profile, does run destructive
> > > unit tests on
> > DB -
> > > same tests developers are required to run. Other for actually
> > > creating
> > the
> > > build, which "skips" the unit tests and does a build with proper
> > properties
> > > so that build can work on QA servers and not destroy the data QA
> > > team has built.
> > >
> > > As far as I can see its just properties file and values get replaced
> > > in maven way. Except for QA build, same unit tests get executed,
> > > only difference being names/locations of external resources changed
> > > based on profile. Only "hack" I can think of is bit of dependency
> > > injection that sets db name slightly differently during unit tests.
> > > The reason behind
> > this
> > > is developers not loosing the "working" data when the destructive
> > > units tests run. But again, its transparent to application and
> > > application just works with the interface, concrete implementation
> > > changes based on
> > whether
> > > its running as part of main app or as unit test.
> > >
> > > Am I missing something?
> > >
> > > Regards,
> > >
> > > Niranjan
> > >
> > >
> > > On 12/21/2012 12:32 PM, Stephen Connolly wrote:
> > >
> > >> http://developer-blog.**cloudbees.com/2012/11/maven-**
> > >> profiles-and-maven-way.html<
> > http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-w
> > ay.html
> > >
> > >>
> > >> Please don't do maven the way you are doing it
> > >>
> > >> On Friday, 21 December 2012, Niranjan Rao wrote:
> > >>
> > >> Greetings,
> > >>>
> > >>> We have bunch of profiles and corresponding resource filtering
> > >>> which
> > all
> > >>> works great. One frequent problem that we encounter team members
> > >>> often forget to add new values in profile/filter property file of
> > >>> other profiles than the one they are currently using. Naturally
> > >>> results are
> > disastrous.
> > >>> Normally we can find quickly which property is not filtered
> > >>> correctly and fix it but this is tedious.
> > >>>
> > >>> I am wondering if there is any way to catch missing properties at
> > >>> build time. That is when maven sees a property definition during
> > >>> filtering phase which has variable declaration and could not
> > >>> locate the value, can it raise the error and let the build fail?
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Niranjan
> > >>>
> > >>> ------------------------------****----------------------------**
> > >>> --**---------
> > >>>
> > >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> > [email protected]>
> > >>> For additional commands, e-mail: [email protected]
> > >>>
> > >>>
> > >>>
> > >
> > > ------------------------------**------------------------------**----
> > > ----- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> > [email protected]>
> > > For additional commands, e-mail: [email protected]
> > >
> > >
> >
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 7838 (20121227) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 7839 (20121227) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
