Dear Todd,
On Tue, 8 May 2012, Thiessen, Todd (Todd) wrote:
> In my experience, I notice a certain lifecycle with builds. They start
> off relatively small but as the releases and years pass, the build grows
> and evolves. More things get tacked on, more modules get added, and so
> forth.
>
>
On Tue, May 8, 2012 at 12:13 PM, Anders Hammar wrote:
> Don't add "-o" to this. That's something different not impacting
> artifacts produced in a multi-module build.
>
Right; I know; it sets the offline status. I used it here to prove a
point: that when present, Maven will not go to remote rep
Don't add "-o" to this. That's something different not impacting
artifacts produced in a multi-module build.
"install" is not required for a multi-module build. (It is sometimes
when using Maven 2, but everyone should be using Maven 3 so this is
not a problem.) The so-called reactor of a multi-mod
On Tue, May 8, 2012 at 12:05 PM, Anders Hammar wrote:
> Doing "mvn dpeloy" on a larger multi-module build will not do this for
> the latter part of the build. So, what you want is "mvn test".
Dumb, slightly tangential question: will mvn -o clean test on a
multi-module build work? My assumption
>> promotes re-use.
>>
>> Anyway, that's my 2 cents.
>>
>>> -Original Message-
>>> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On
>>> Behalf Of Curtis Rueden
>>> Sent: Monday, May 07, 2012 4:32 PM
>>&
ssage-
From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On
Behalf Of Curtis Rueden
Sent: Monday, May 07, 2012 4:32 PM
To: Maven Users List
Cc: Johannes Schindelin
Subject: Reducing SNAPSHOT redundancy
Hi everyone,
I have a question about snapshot deployment.
I have a multi-module p
en.w...@gmail.com] On
> Behalf Of Curtis Rueden
> Sent: Monday, May 07, 2012 4:32 PM
> To: Maven Users List
> Cc: Johannes Schindelin
> Subject: Reducing SNAPSHOT redundancy
>
> Hi everyone,
>
> I have a question about snapshot deployment.
>
> I have a multi-module
How many build plans do you have? If I understood correctly single plan for
all modules (perhaps on aggregate pom).
Even small change in one module rebuilds all modules :-(
Let's consider to define one build plan for each module. In addition define
dependencies between build plans to reflect depen
I am not a big fan of the automatic triggering of builds.
We have over 60 modules.
The batch building might make sense at the beginning of a product where
the modules are poorly defined and changes affect a lot of modules and
functionality shifts between projects quite often.
As we got into
On Mon, May 7, 2012 at 4:31 PM, Curtis Rueden wrote:
> However, there is a lot of redundancy between snapshot JAR files. Often, a
> commit will involve only one of the 30 submodules, but all 30 will
> ultimately be rebuilt and redeployed, resulting in a plethora of snapshot
> versions.
> I was
> So my question is: is there a common Maven best practice to mitigate such
> redundancy? Or do most people simply live with the proliferation of
> snapshots that occurs when using a naive deployment scheme?
I can't speak for "most people" but I can say that in my experience,
people simply live wi
Hi Anders,
Thanks for your reply.
> I believe the common way to handle this is to schedule purging of old
> snapshots in the repo manager. At least that's how I handle it in my
> setups.
>
Indeed, our Nexus is set to purge old snapshots daily, deleting any that
are more than 7 days old. This wo
I believe the common way to handle this is to schedule purging of old
snapshots in the repo manager. At least that's how I handle it in my
setups.
/Anders
On Mon, May 7, 2012 at 10:31 PM, Curtis Rueden wrote:
> Hi everyone,
>
> I have a question about snapshot deployment.
>
> I have a multi-modu
Hi everyone,
I have a question about snapshot deployment.
I have a multi-module project with ~30 modules, all in a Git repository on
GitHub. Whenever someone pushes to the repository, a GitHub notification
hook pings our Jenkins to do a rebuild, which includes a redeploy to our
Nexus. This is all
14 matches
Mail list logo
