Re: [jbosstools-dev] BuildContext in M2E Builders
m2e's incremental buildcontext is backed by an IResourceDelta which
references all files modified by a user, during an incremental build.
All files generated *during* the build, by build participants, mojo,
whatever, are not part of that initial delta.
I'm not sure it's possible to track all resources modified during the
build. Basically, all maven plugins would need to implement the
incremental build API for once, and all of them would need to tell the
build context what has changed, including for example all the compiled
classes. This would probably even require changes to the buildcontext
api.
I suggest you bring the discussion over to m2e-dev list, as I think
it's an interesting challenge.
Try to ping me on IRC, see if we can find a workaround for your
specific use case.
Fred
Le jeudi 3 octobre 2013 02:52:03, Rob Cernich a écrit :
Hey all,
I've been deep in the SwitchYard M2E build participant recently trying to figure out
why we're ending up with stale markers in the workspace. One thing I've found is
that items refreshed by the resources mojo don't show up until they are refreshed by
the m2e builder, which happens after all the build participants have executed (i.e.
refreshes the files passed to BuildContext.refresh()). This is problematic for me because
I'm using scanners created off the context to check for changed files and am missing
changes to resource files that have been copied to target/classes. My plugin is executing
in the process-classes phase, so I would expect the updated resources to be available.
I'm not a Maven expert, but it seems to me that if I'm scanning for changed
files, I should be able to see _all_ the files that have changed, including those changed
as a result of previous executions in the same context. I would consider the current
behavior a bug in the Eclipse BuildContext, but I'm not sure how it's supposed to
work to begin with. If any of you m2e experts could chime in with your thoughts, that
would be much appreciated.
Thanks in advance,
Rob
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev