Hi,
On his blog, Lex Spoon makes some interesting points against most
build systems, using Maven as an example:
http://blog.lexspoon.org/2012/12/recursive-maven-considered-harmful.html
In related news, I've heard people complain about “insanely long build
times via building unnecessary things” and
Mark Struberg has started work to improve the incremental behavior of e.g.
the compiler plugin. Version 3.0 of maven-compiler-plugin includes an early
version of that new library. There was a thread about this, started by
Mark, on the dev list some ago if you want to read about it.
Mark has also w
Current work on Maven compiler plugin version 3.0 is adding support for an
incremental mode.
It is a tricky balance to cut, as if incremental mode is too aggressive,
you compile more than is strictly necessary... and if too lax, you compile
less than is required and people end up having to run "cl
I really like to pick up the work again, but currently busy with graduating
another project.
The next important points to do are
* inter-project change detection. If you have a dependency to another project
which changed, you need to basically do a full build on your depending module.
Thus sai
Rick depends on where you place declaration in your build.xml global
declaration with http://ant.apache.org/manual/Tasks/property.html
target-local override with http://ant.apache.org/manual/Tasks/local.html
is this what you're looking for?
Martin
__
On Dec 17, 2012, at 3:59 , Martin Gainty wrote:
> Rick depends on where you place declaration in your build.xml global
> declaration with http://ant.apache.org/manual/Tasks/property.html
> target-local override with
> http://ant.apache.org/manual/Tasks/local.html
> is this what you're looking
On 17 December 2012 03:28, Rick Mann wrote:
>
> On Dec 16, 2012, at 18:06 , Benson Margulies
> wrote:
>
> > You'll have to be a lot more specific. With the antrun plugin? With
> > something else?
>
> I've posted a couple times with my specific query, but no replies to it. I
> set it up a long ti
with respect to 'the install hack': If I had a dollar for every
occasion where a bug in a plugin or the core required me to use it,
I'd be a richer man by a considerable amount.
-
To unsubscribe, e-mail: users-unsubscr...@maven.ap
On Dec 17, 2012, at 4:18 , Stephen Connolly
wrote:
> that is maven Ant tasks.
>
>
> The scope element is used when you have specified "scopes" attr in
> *however* it is really only of use when you have a
> pomRefId as there is no other way to reference a different set of scopes.
>
> So the
And I try to remove such bugs as and when I find them... but yes I agree
it's a pain... but people should be more aware that it is a hack and they
would be better served by fixing the root cause... not applying the
"install" hack
On 17 December 2012 12:26, Benson Margulies wrote:
> with respect
The problem is also with Java itself.
Let's take a project with a war depending of a jar produced by another
module or an ear relying on several war and you cannot use anymore
something below install (it should be package to at least find the archive
in the target dir and not to have to find it in
Reformatted and edited into something a bit more specific:
http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html
On 17 December 2012 12:45, Stephen Connolly wrote:
> And I try to remove such bugs as and when I find them... but yes I agree
> it's a pain... but people should be more awa
On Mon, Dec 17, 2012 at 12:36 PM, Stephen Connolly
wrote:
> Current work on Maven compiler plugin version 3.0 is adding support for an
> incremental mode.
>
> It is a tricky balance to cut, as if incremental mode is too aggressive,
> you compile more than is strictly necessary... and if too lax, y
On Mon, Dec 17, 2012 at 12:47 PM, Mark Struberg wrote:
> I really like to pick up the work again, but currently busy with graduating
> another project.
>
> The next important points to do are
>
> * inter-project change detection. If you have a dependency to another project
> which changed, you n
On Mon, Dec 17, 2012 at 2:08 PM, Arnaud Héritier wrote:
> But yes all plugins should have an update/incremental behavior but it's not
> easy to do because there are many factors that may require to rebuild some
> parts of your project (You may edit your settings.xml, a pom.xml ).
> It's not (s
how do you know the resource handling is not depending on other jars?
I know this is not perfect, but if you have a bigger project then you have a
tree of depending modules. And not every module is depending on any other. So
while a forced 'clean' on _those_ depending modules is more expensive
On Mon, Dec 17, 2012 at 3:36 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Another issue is that people abuse the "install" hack far more often than
> they should...
>
Hi; this is the first I've read anywhere about the "install hack". Where
can I find out more about it?
> In
By default it should be fine to use the 'mvn verify' build lifecycle step [1].
In that case the 'reactor' does not reference the project dependencies via the
local maven repo but instead via path JVM references to the other modules in
the build directly.
LieGrue,
strub
[1]
http://maven.apac
On 17 December 2012 15:34, Laird Nelson wrote:
> On Mon, Dec 17, 2012 at 3:36 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Another issue is that people abuse the "install" hack far more often than
> > they should...
> >
>
> Hi; this is the first I've read anywhere about
On Dec 17, 2012, at 11:02 AM, Stephen Connolly
wrote:
> On 17 December 2012 15:34, Laird Nelson wrote:
> I am not saying that you only ever run it with "clean verify"
>
> I am not saying running with "clean install" is considered harmful.
>
> I am saying that *if* you _need_ to use "clean in
Last month I head the idea to only show the -rf option if you ran Maven
with at least the install goal. The next step was to fix this, either with
serialization of the MavenProjects or xml-file which could be picked when
continuing the build with the -rf argument. Hence, why not work on that
Hi All,
I am trying to find a tag/way so that I can get the source code for the
dependency in Maven. I have dependency as
my-group
my-artifact
${my-version}
I have other dependencies also but I want source code from this dependency
only.
Thanks
--
View this message in context:
http
Source code where? sitting in a jar? Accessible in an IDE?
On Mon, Dec 17, 2012 at 8:34 PM, anjibman wrote:
> Hi All,
>
> I am trying to find a tag/way so that I can get the source code for the
> dependency in Maven. I have dependency as
>
>
> my-group
> my-artifact
> ${my-version}
>
>
>
hi, you can use dependency plugin like "mvn dependency:sources
-DdownloadSources=true".
2012/12/18 anjibman :
> Hi All,
>
> I am trying to find a tag/way so that I can get the source code for the
> dependency in Maven. I have dependency as
>
>
> my-group
> my-artifact
> ${my-version}
>
>
24 matches
Mail list logo
