Iteration using Java's for?
by Ondrej Zizka
Hi,
is there a reason against querying the graph, storing it to Java
variable, iterating it using for( Foo foo : foos ), and skipping the
varstack and when() etc?
Basically, the current rules structure is appropriate for e.g. XML based
rules whose XSD would translate to this structure, but if we provide
Java and Groovy, the above way would be shorter to write, and users
might tend to do that.
Thanks,
Ondra
11 years, 9 months
Negative queries?
by Ondrej Zizka
When talking to Robb, we discussed the ability to query for POJO classes
- i.e. those which do not have any vendor-specific extension, do not use
blacklisted classes, do not extend something "dirty", etc.
Which brings us to interesting concept - querying for something "not
being a lot of things".
We have discussed this briefly on F2F with Brad.
The first shot could be:
* creating a method which will query for vertexes that have some frame
type (JavaClass), but not any other, or a set of other types
(WebLogicContextListener).
* querying for vertices which are not linked to vertices in sevral
blacklists
For example, querying for JavaClass'es not linked to a list of
other JavaClass'es by an "extends" edge.
This will need some way to keep the blacklists in the graph, and
then, I can imagine Gremlin taking the part in filtering out the
vertices linked to them by a set of edge types ("extends", "implements",
"annotatedBy", "calls", "imports", ...)
And creating a disjunction of all these results, by narrowing the set of
candidate vertices, step by step.
What I think is a BAD approach, is this kind of rules (outside of Java
basic analysis):
Query.find(JavaClassModel.class).as("javaClasses")
Iteration.over("javaClasses").as("javaClass").perform(
...
)
my2c,
Ondra
11 years, 9 months
.when( new True() )
by Ondrej Zizka
Hi,
I found this rule being invoked many many times.
Since there's just .when( new True() ) and not some iteration, I wonder
what are the elements that it executes over so many times.
And how do I get this information from the current API?
Thanks,
Ondra
ruleSet("ExampleGroovyRule").setPhase(RulePhase.MIGRATION_RULES)
.addRule()
.when(
new True()
)
.perform(
new GraphOperation () {
public void perform(GraphRewrite event, EvaluationContext
context) {
//System.out.println("Performing rewrite operation")
Logging.of(this.getClass()).info("Performing rewrite
operation in ExampleGroovyRule");
}
}
11 years, 9 months
Where to store intermediate data?
by Ondrej Zizka
Hi,
where should I cache intermediate data? E.g. the model metadata.
I expected GraphContext to have some Map-like API, there's none.
Should I add it? Or should I clutter the API with it? Or will it be
better to store it in the graph afterall?
Thanks,
Ondra
11 years, 10 months
RuleModel et al.
by Ondrej Zizka
We should have $subj:
We need to refer to the rules in the report.
We agreed to store all information in the graph.
Current ID is not guaranteed to be the same over runs.
Current ID has no namespaces.
my2c.
Ondra
11 years, 10 months
Legacy Classifications and Decorators in separate rules
by Ondrej Zizka
Hi,
by accident, I saw this discussion.
(20:07:51) mbriskar: lincolnthree: but if you plan to have
classification in one rule and it's decorators in the another rules,
there is no other way then to save it in the graph
(20:07:57) LincolnBaxter: mbriskar: meta-model == windup's java
in-memory representation of the project…. look at the code
(20:08:35) LincolnBaxter: mbriskar: why would classifications and
decorators be in separate rules?
(20:08:42) mbriskar: *lincolnthree, jsightler, ozizka: sorry but I just
feel all of you have a different thinking of how to migrate that makes
me confused as ...*
(20:08:57) mbriskar: never
(20:09:15) mbriskar: lincolnthree: that's what Ondra thinks
(20:13:33) LincolnBaxter: mbriskar: i don't think they should be in
separate rules either
So, why should it be in separate rules?
Not sure if you (whoever) have really seen what those classification and
decorator does.
Probably you think it compares to WHEN and PERFORM. It does not.
At least not always.
I'll gladly remind what was decided on the F2F (correct me if I
misunderstood) :
We will store the intermediate information into the graph, making the
rules decoupled.
E.g. we will go through the files, using rules, and examine what they are.
Then, with another rules, we will query the graph and process the files
in some other way.
In other words, we already do classify using some rules, and decorate
using others.
The limitation of the legacy Windup rules is that they are a tree. The
context of one classifier is lost after it's processed.
If you want to do the same operation in other classifier, you have to
copy it.
For example: If you classify FooBar XML file A) by namespace
http://foo.com/bar B) by finding an /foo-bar element in it, then
whatever you do with them has to be coded twice.
We do not want to mimick this limitation. Therefore, we want one rule
for A, other rule for B, and third rule for whatever is done with them next.
Regards, Ondra
11 years, 10 months
Windup Meeting Minutes: 2014-06-23
by Lincoln Baxter, III
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
Meeting summary
---------------
* Agenda (lincolnthree, 13:50:19)
* Status Updates (lincolnthree, 13:54:41)
* Currently working on migrating all the xml-legacy rules using the
class diagram here (
http://tinypic.com/view.php?pic=deaava&s=8#.U8-RYTlNLqV )
(mbriskar, 13:55:46)
* Working on refactoring the Black/WhiteList models/system to use a
different approach. May or may not make more sense, but will review
once complete. I think it can simplify how this works.
(lincolnthree, 13:58:23)
* Spent a large amount of time reviewing PRs over the last few days.
(lincolnthree, 13:58:42)
* Will be on PTO starting Friday, and will be gone for a week.
(lincolnthree, 13:58:55)
* Working on XSLT based reporting + utils. (ozizka, 14:01:25)
* Also editing wiki here and then (ozizka, 14:02:31)
* I'll create a smaller app for tests (ozizka, 14:03:16)
* Also added the // @formatter:off/on stuff, if that counts ;-)
(ozizka, 14:03:40)
* I am working on freemarker reporting (jsightler3, 14:04:40)
* I have a basic project overview report that displays all files that
have been classified (or contain blacklists) (jsightler3, 14:05:23)
* also source display with online hints in separate reports
(jsightler3, 14:05:52)
* next up is supporting the addition of custom reports that will
automatically be added to the navbar (jsightler3, 14:06:38)
* Minor workflow change - pull requests required for all changes
(lincolnthree, 14:08:17)
* Just to officially log this. We've moved to a 100% pull request
required change model. All changes must be reviewed, +1'd before
merging. (lincolnthree, 14:09:09)
* Review must be completed by a senior team member (Ondra, Lincoln,
Jess) (lincolnthree, 14:09:37)
* If no review is available due to PTO or other absense, the Pull
Request must wait to be merged until review can be completed.
(lincolnthree, 14:10:13)
* How much to stick to the idea of putting stuff to the graph?
* Logging - JUL configuration (lincolnthree, 14:26:01)
* LINK: https://issues.jboss.org/browse/WINDUP-73 (ozizka, 14:33:02)
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
11 years, 10 months
Rename one of 2 perform()s?
by Ondrej Zizka
Hi,
we have 2 perform() methods: One for the rule, one for operation.
With the anonymous inner operations, this gets confusing:
ConfigurationBuilder.begin().addRule().
.perform(
new Operation(
.perform(
// Nested iteration
.perform(
new AnotherOperation(){
.perform( ... ){
}// end
perform()
}
)// end perform()
//
)// end perform()
)
)
;
Too many perform()'s.
I know this comes from OCP. I suggest to change it there.
Name can be anything, e.g. execute(), do(), wouldYouMind(), ... :)
WDYT?
Ondra
11 years, 10 months
Maven deps again
by Ondrej Zizka
Hi,
looking at Reporting API:
<dependency>
<groupId>org.jboss.windup.config</groupId>
<artifactId>windup-config-api</artifactId>
<version>${project.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.jboss.windup.graph</groupId>
<artifactId>windup-graph-api</artifactId>
<version>${project.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.jboss.windup.utils</groupId>
<artifactId>utils</artifactId>
<version>${project.version}</version>
<scope>provided</scope>
</dependency>
These are provided, but not an addon. I guess that's not correct, right?
FWIR it should be either an addon + provided scope or api + compile scope.
Or not?
Thanks,
Ondra
11 years, 10 months