Op Sat, 01 Sep 2012 14:40:11 +0200 schreef Jason van Zyl <ja...@tesla.io>:
On Sep 1, 2012, at 6:21 AM, Mark Struberg wrote:
Hi!
While doing further research on the incremental build I came accross the
org.sonatype.plexus.build.incremental.BuildContext.
There are a few things around this class which caught my interrest.
1.) This class has a package org.sonatype, the artifact name groupId
org.codehaus.plexus and the project in git is sisu-build-api.
Quite confusing...
Hence we haven't really published anything. As you will discover
incremental builds, or build avoidance as we've been calling it, when
taking into consideration all tools and contexts is hard. The most
advanced form of build avoidance exists in m2e has much of the
implementation bits required. But obviously we don't want any tools
depending on m2e. Like Maven depending on m2e isn't acceptable. The
latest of our work is here:
https://github.com/etesla/tesla-build-avoidance
It works but it's not complete, the API is not where we want it and
there are a couple branches there too. We have proven we can make
plugins just work in m2e which is a primary goal. The current changes
that Igor has experimented with in the core are here:
https://github.com/etesla/maven-3/tree/build-context-injection
And the m2e work is here:
https://github.com/etesla/m2e-core
But he doesn't particularly like it. So we don't even like all the ideas
or implementations but it's been there for a long time. Initially
started by Benjamin, Igor picked up the work and now Igor and I are
looking at it again in the context of continuous delivery. But it is
confusing because we're still not entirely clear on how we would like it
to work but currently we feel using the concept of something like an
Eclipse workspace. This idea can work in many tools. I'm not only
interested in Maven.
I also don't want to go puttering around in the core because I believe
that with some very tiny changes experiments can be done in a simple
say. One, maybe two injection sites and a custom scope and anything is
possible.
2.) This replaced our internal scanning. What wonders me a bit is that
the DefaultBuildContext always returns true for hasDelta(). Not sure
about the original impl, but thiw might need to get changed if we like
to support incremental builds. The problematic code can be found in
DefaultMavenResourcesFiltering. Not sure if this got used somewhere
else as well.
3.) Having the BuildContext API in a m2eclipse related package is not
exactly wise imo. This makes m2eclipse depending on maven and maven
depending on m2eclipse.
As Anders pointed there is no dependency on m2e. And if we do take code
from m2e, which we will because it's the most advance/proven build
avoidance code there is, then we would extract it.
If you consider Maven and m2e as 2 separate products, then I have to agree
with Mark that this looks like a cross reference between the two. It would
make more sense if Maven would offer such interfaces/API.
Wdyt? How to proceed?
I suggest just looking around the code. Once the JSR-330 branch is
merged then it might be easier to play around with. I have no doubt it
can be implemented because it has been effectively done in m2e for
years. But making it accessible, and making an API that will stand the
test of time is what I'm interested in, and I'm also keen on trying to
make this available to other systems. By this I don't mean Tesla but
other tools like SBT, Gradle, Leiningen, Hudson, and Jenkins because
they all have the similar requirements for build avoidance.
LieGrue,
strub
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
I never make the mistake of arguing with people for whose opinions I
have no respect.
-- Edward Gibbon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
