Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324284

Summary:

Allow contribution of a "post generation" action

Product:

[Technology] Tigerstripe

Reporter:

Richard Craddock <rcraddoc>

Component:

Core

Assignee:

Project Inbox <tigerstripe.core-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

enhancement

Priority:

CC:

danijoh2, nmehrega

Version:

unspecified

Target Milestone:

0.5M0

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
patch_324284.txt	none
patch_324284.txt	none
patch_324284.txt	none
patch_324284.txt	none
patch_324284.txt	none

Description Richard Craddock

2010-09-02 05:34:08 EDT

We need to be able to execute actions after a generation run of a project has completed. This would typically be used to perform some kind of deployment action based onteh gereated artifacts eg - copy to a given location, start some other build process etc.

These actions should be contributed through an extension point, and will be run once generation has completed.

Execution of any given action should be possible on "sucessful generation only", "unsuccesful generation only" or "always".

The actions will require access to certain key arguments (probabaly passed through the execute() call ?):

a) The TigerstripeModelProject that was generated against - enabling access to all arguments such as outputDirectory, plugin config settings etc. ( so we can find the generated artifacts!)

b) The result from the generation run (ie indication of success/failure (per plugin) , exceptions in case of failure etc)

Once actions have been contributed, it should be possible to enable/disable them for any given TigerstripeProject through the tigerstripe.xml project descriptor

Comment 1 Navid Mehregani

2010-09-02 10:23:33 EDT

(In reply to comment #0)
> Execution of any given action should be possible on "sucessful generation
> only", "unsuccesful generation only" or "always".

Out of curiosity, why would you want to execute them on an unsuccessful generation? Isn't this error-prone? If user specifies "always" by mistake in their action, it'll be difficult for them to figure out what's going wrong in their action when the generated artifacts are stale or do not exist.

Comment 2 Richard Craddock

2010-09-02 10:29:33 EDT

(In reply to comment #1)
> (In reply to comment #0)
> > Execution of any given action should be possible on "sucessful generation
> > only", "unsuccesful generation only" or "always".
> 
> Out of curiosity, why would you want to execute them on an unsuccessful
> generation? Isn't this error-prone? If user specifies "always" by mistake in
> their action, it'll be difficult for them to figure out what's going wrong in
> their action when the generated artifacts are stale or do not exist.

I'm trying to be as flexible as possible - in the past we have painted ourselevs in to a corner by doing emnehnacemenst "the way we imagined they would be used" only to find someone else has a different use.

I was thinking a "failure" action might do some clean up...but I have no real use case..

Comment 3 Daniel Johnson

2010-10-18 21:10:26 EDT

Should this extension point alert when each plugin finishes generating, or just once after all plugin generations are complete? Also, from what I see Tigerstripe Projects are the only projects that have Generate enabled, is this correct? And finally, what is our standard for logging exceptions vs. showing exceptions in a message dialog vs. crashing? I assume for this anything that goes wrong should just be written to a log file or the error log or something. I should be able to commit a patch once these questions are answered, but will need more help coming up with test cases, as I don't know the process or the required coverage.

Comment 4 Richard Craddock

2010-10-19 04:18:58 EDT

(In reply to comment #3)
> Should this extension point alert when each plugin finishes generating, or just
> once after all plugin generations are complete? Also, from what I see
> Tigerstripe Projects are the only projects that have Generate enabled, is this
> correct? And finally, what is our standard for logging exceptions vs. showing
> exceptions in a message dialog vs. crashing? I assume for this anything that
> goes wrong should just be written to a log file or the error log or something.
> I should be able to commit a patch once these questions are answered, but will
> need more help coming up with test cases, as I don't know the process or the
> required coverage.

This should only consider a "full run" - ie when all plugins havve completed.

This is a pure Tigerstripe feature, so only needed for Tigerstripe projects.

Crashing is a bad idea :-)
At the moment, the generation run completes and the status is shown in a message dialog. That message is also logged. 

I'm not sure how this would work, but is it possible to append the output of any post generation action to teh messages that show up in the Message dialog, and also to the log. ( You could think of this as adding another Status to the plugin run statuses, but again, not sure how that would work in practice).

Comment 5 Daniel Johnson

2010-10-19 14:10:50 EDT

Created attachment 181212 [details]
patch_324284.txt

Added the generateComplete extension point to org.eclipse.tigerstripe.workbench.base. I have yet to add any test cases, but I created a sample to prove that it works (SampleGenerateCompleteListener). To see it in action just add a new generateListener extension and point the class to the SampleGenerateCompleteListener class. Then run generate on a tigerstripe project with at least one plugin enabled.

New:
GenerateCompleteManager
IGenerateCompleteListener
SampleGenerateCompleteListener
generateComplete.exsd

Changed:
NewTigerstripeRunWizard
org.eclipse.tigerstripe.workbench.base.plugin.xml

I will hold off on marking my task complete until I know that this is all the functionality that is needed.

Comment 6 Daniel Johnson

2010-10-20 18:20:40 EDT

Created attachment 181345 [details]
patch_324284.txt

Same as last patch except I moved the logic to call the extension point notifier from NewTigerstripeRunWizard to the actual generate method in TigerstripeProjectHandle as this seems to be the more correct way. I believe I updated all test cases that utilize this method.

New:
GenerateCompleteManager
IGenerateCompleteListener
SampleGenerateCompleteListener
generateComplete.exsd
TestGenerateCompleteFramework

Changed:
TigerstripeProjectHandle
TestProjectGenerationBasics
TestM1Generation
o.e.t.workbench.base.plugin.xml
o.e.t.workbench.base.test.plugin.xml

I will hold off on marking my task complete until I know that this is all the
functionality that is needed.

Comment 7 Daniel Johnson

2010-10-20 18:22:20 EDT

^ Meant to mention I added/updates test cases as well.

Comment 8 Daniel Johnson

2010-10-21 15:49:14 EDT

Created attachment 181443 [details]
patch_324284.txt

Made some changes as per comments from Richard.
Now calling the framework from the end of the M1Generation.run method.
Made GenerateCompleteManager a singleton to ensure better performance.
Updated all test cases.
Note: I am testing the framework directly that a ON_SUCCESS listener gets notified when a bogus generation passes, and that it doesn't get called when i pass in a bogus generation failure. I am also testing in the generation framework that it is being called on success, but I could not find a way to make a generator fail when called from the generation framework to be sure the listener was not notified. If anyone knows a good way to make a generator fail (not the generation framework!) than we could add another test case to be sure the listener is not being notified when called from the generation framework. I do not think this is a big deal since I am testing the framework directly though.

Navid, you can start on a sample listener if you want, please refer to SampleGenerateCompleteListener in the test folder for a simple starting point. Let me know if you think the listeners could use more information than what I am passing them.

New:
GenerateCompleteManager
IGenerateCompleteListener
generateComplete.exsd
SampleGenerateCompleteListener
TestGenerateCompleteFramework

Changed:
TigerstripeProjectHandle
TestM1Generation
TestProjectGenerationBasics
o.e.t.workbench.base.plugin.xml
o.e.t.workbench.base.test.plugin.xml
NewTigerstripeRunWizard

Comment 9 Daniel Johnson

2010-11-01 11:42:15 EDT

Created attachment 182151 [details]
patch_324284.txt

Forgot to add generateComplete.exsd in patch.

Comment 10 Daniel Johnson

2010-11-01 11:58:40 EDT

Created attachment 182152 [details]
patch_324284.txt

Also M1Generator. NOTE: No changes were made to TigerstripeProjectHandle like mentioned in previous comments.

Comment 11 Richard Craddock

2010-11-01 12:35:59 EDT

Patch form Daniel reviewed and applied.