[jbosstools-dev] BuildContext in M2E Builders

Rob Cernich rcernich at redhat.com
Fri Oct 4 14:35:57 EDT 2013


After reading through some of the Maven documentation, I don't think my expectations are correct.  The scanners simply provide a list of files, but I don't think they're supposed to actually identify changed files.  I base this on the fact that there is an isUptodate() method on BuildContext itself.  That said, I'll modify my logic accordingly.

Thanks again for the responses.

----- Original Message -----
> > Looking deeper at the buildcontext mechanism, it appears there might be
> > a solution :-)
> > So basically, the maven-resources-plugin invokes
> > buildContext.refresh(file) for each modified file. It does nothing but
> > keeping tabs on what's changed.
> >  From your plugin, you can access buildContext.getFiles(), which will
> > give you all the files tagged to be refreshed during the build. That
> > should do it, hopefully.
> 
> I'll try to pursue this approach.  It may be a bit more work, but the
> solution would probably be pretty close to the patch for m2e.  I'll see what
> I can work up.
> 
> Thanks again.
> 
> > 
> > Fred
> > 
> > Le jeudi 3 octobre 2013 11:12:46, Fred Bricon a écrit :
> > > 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 at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> > >
> > >
> > > _______________________________________________
> > > jbosstools-dev mailing list
> > > jbosstools-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> > 
> > 
> > 
> 
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev



More information about the jbosstools-dev mailing list