sweet talk (part 2) tool support for sweet
DESCRIPTION
Sweet Talk (part 2) Tool Support for Sweet. Phil Quitslund. Plan. Sweet Tooling issues Introduction to Eclipse Sweet Plugin at a glance Implementation notes Pitch and Caveats Where next. Plan. Sweet Tooling issues Introduction to Eclipse Sweet Plugin at a glance Implementation notes - PowerPoint PPT PresentationTRANSCRIPT
Sweet Talk (part 2)Tool Support for Sweet
Phil Quitslund
Plan
1. Sweet Tooling issues
2. Introduction to Eclipse
3. Sweet Plugin at a glance
4. Implementation notes
5. Pitch and Caveats
6. Where next
Plan
1. Sweet Tooling issues
2. Introduction to Eclipse
3. Sweet Plugin at a glance
4. Implementation notes
5. Pitch and Caveats
6. Where next
Automating the BuildThe Problem: Manual builds considered painful
Automating the Build
• generative techniques require extra steps to stage builds
The Problem: Manual builds considered painful
Automating the Build
• generative techniques require extra steps to stage builds
The Problem: Manual builds considered painful
the rub: manual builds hurt and interrupt programmer flow
public abstract class List { public case Nil public case Cons(private int head, private List tail)}
public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }
Automating the Build
Automating the Build
public abstract class List { public case Nil public case Cons(private int head, private List tail)}
public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }
Automating the Build
3 “Introductions”
public abstract class List { public case Nil public case Cons(private int head, private List tail)}
public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }
Automating the Build
public abstract class List { public case Nil public case Cons(private int head, private List tail)}
public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }
Automating the Build
repositoryS
Automating the Build
repository
J
J
JS
Automating the Build
repository
J
J
JS
C
C
C
Managing DependenciesThe Problem: Crufty Orphans
Managing Dependencies
• generated files are "orphaned" when their introductions get removed.
The Problem: Crufty Orphans
Managing Dependencies
• generated files are "orphaned" when their introductions get removed.
The Problem: Crufty Orphans
the rub: manual maintenance is tedious and error prone
Managing Dependencies
repository
J
J
JS
C
C
C
Managing Dependencies
repository
J
J
JS
C
C
C
Managing Dependencies
repository
J
J
JS
C
C
C
Managing Dependencies
repository
J
J
JS
C
C
C
Managing Dependencies
repository
J
J
S
C
C
C
Managing Dependencies
repository
J
J
S
C
C
Managing Dependencies
repository
J
J
S
C
C
Done manually this is tedious and prone to error!
Error Handling
The Problem: Say What?
Error Handling
• Errors in generated files can be hard to trace back to their source
The Problem: Say What?
Error Handling
• Errors in generated files can be hard to trace back to their source
The Problem: Say What?
the rub: indirection decreases understandability
public abstract class List { public case Nil public case Cons(private int head, private List tail)}
public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }
Error Reporting
public abstract class List { public case Nil public case Cons(private int head, private List tail)}
public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }
Error Reporting
Legal Sweet
public abstract class List { public case Nil public case Cons(private int head, private List tail)}
public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } case Nil { return 1; }
Error Reporting
Legal Sweet?
Error Reporting
public abstract class List { public case Nil public case Cons(private int head, private List tail)}
public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } case Nil { return 1; }
Legal Sweet? Nope…
Error Reporting
Conflicting declarations
public abstract class List { public case Nil public case Cons(private int head, private List tail)}
public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } case Nil { return 1; }
Error Reporting (from 10,000ft)
repository
S
S
S
Error Reporting (from 10,000ft)
repository
S
S
S
Error Reporting (from 10,000ft)
repository
S
S
S
Error Reporting (from 10,000ft)
repository
S
S
S
Error Reporting (from 10,000ft)
repository
S
S
S
Plan
1. Sweet Tooling issues
2. Introduction to Eclipse
3. Sweet Plugin at a glance
4. Implementation notes
5. Pitch and Caveats
6. Where next
What is Eclipse?
• A universal platform for integrating development tools– “An IDE for everything and nothing in
particular”
• An open, extensible architecture based on plug-ins
What is Eclipse? (a picture)
Platform Runtime
Workspace
Help
Team
Workbench
JFace
SWT
Eclipse Project
JavaDevelopment
Tools(JDT)
Stellation
SweetPlugin
AnotherTool
Plug-inDevelopmen
tEnvironment
(PDE)
Eclipse Platform
Debug
What is Eclipse?
• Lot’s for free (well almost)– Tight integration of common core tools
• CVS, Ant, JUnit, diff
– Extensible/open architecture
• Third-party plugins– ruby, c#, php, etc.– AOSD (aspectJ, hyperJ, FEAT, JQuery, etc)
Plan
1. Sweet Tooling issues
2. Introduction to Eclipse
3. Sweet Plugin at a glance
4. Implementation notes
5. Pitch and Caveats
6. Where next
Plugin Features
• Keyword awareness
• Integrated SweetBuilder
• Automated House-Cleaning
• Artifact Special Treatment
• Basic Error-Reporting
• Integrated Help
DEMO!!
Cross fingers please…
Plan
1. Sweet Tooling issues
2. Introduction to Eclipse
3. Sweet Plugin at a glance
4. Implementation notes
5. Pitch and Caveats
6. Where next
Automating the Build (Impl.)
- Eclipse leverages the Observer (Listener) Design Pattern
The idea is to register listeners to monitor for changes to resources that should trigger a build.
Automating the Build (Impl.)
• Our pipeline:
Automating the Build (Impl.)
• Ordered list of builders
• Insert SweetBuilder before JavaBuilder
• Our pipeline:
SB
JB
Managing Dependencies (Impl.)
/
pkgA pkgB pkgC
ouptut/
pkgA pkgB pkgC
Possible Approach: Parallel Worlds
Managing Dependencies (Impl.)
/
pkgA pkgB pkgC
ouptut/
pkgA pkgB pkgC
Possible Approach: Parallel Worlds
Possible Solution: “make clean”
Managing Dependencies (Impl.)
- Complete rebuild
- Worst case every Java file re-compiled
- File-based
- subtler: de-values artifacts• In a multi-view setting should be first-class!
Parallel Worlds Disadvantages
Managing Dependencies (Impl.)
- Use Sweet Parser to collect Introductions
- Store in Resource object metadata
Advantages:– Persistence for free– Limited introduction/deletion ripple
Better: Mapping
Error Reporting (Impl.)
- Should be integrated into environment- Shouldn’t re-route programmer flow- Minimize dissonance
Ideal: Handle Like Errors NOT Exceptions!
Error Reporting (Impl.)
- Extended Sweet Handler to collect Problem data
- Data marshalled into a Marker object
- Attached to Eclipse Resource
Result:
- visual (localized) cues, persistence, navigability
Eclipse Resource Marker Strategy
Plan
1. Sweet Tooling issues
2. Introduction to Eclipse
3. Sweet Plugin at a glance
4. Implementation notes
5. Pitch and Caveats
6. Where next
Pitch
• Nice vision– “user as programmer”
• Nice Execution– Mature tool for Java and Plugin Development
• Growing market share– Research and Industry
• Active Developer Community• In short: a viable tool to leverage now
– http://www.eclipse.org
Caveats
• Steep Initial Learning Curve
• Lagging Documentation– but “system is the curriculum…”
• Designer Bias– “strong world view”– pervasively file-oriented
Plan
1. Sweet Tooling issues
2. Introduction to Eclipse
3. Sweet Plugin at a glance
4. Implementation notes
5. Pitch and Caveats
6. Where next
Where next
• Short Term– Plugin improvements
• Export metadata (introductions) to Ant• More sophisticated Error Reporting• Context visualization
– Sweet Programming Guide
• Long Term– Multi-view support
Programming in the 21st century
• Emphasis on“ilities”– Reusability, evolvability, etc.– What about the “archies?” (hier/heter)
• The rub: current SOC technologies (HyperJ, AspectJ, etc) depose the dominant decomposition only to replace it with their own!
• It remains to be seen if their decomposition is any better!• Polyphonic Programming!
• The time for multi-view AOSD Tool-support is now!