From lincolnbaxter at gmail.com Tue Jul 1 19:13:35 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Tue, 1 Jul 2014 19:13:35 -0400
Subject: [windup-dev] Please clean up unused branches in windup/windup
Message-ID: <CAEp_U4HaKa2sRu=KoQHYiuBRZDpE9ui2ArmUsKGnok5hS56Fbg@mail.gmail.com>
If you have created branches in windup/windup that are no longer required,
please remove them now. We have moved to a "pull request required"
contribution model, so branches in upstream should no longer be required
(you should use a branch in your own fork)
I will be performing branch cleanup on Friday, so if there is a branch that
you do not want deleted, please reply to this thread and let me know. Thank
you.
Thank you!
~Lincoln
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140701/0b497912/attachment.html
From ozizka at redhat.com Wed Jul 2 06:11:59 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 02 Jul 2014 12:11:59 +0200
Subject: [windup-dev] Please clean up unused branches in windup/windup
In-Reply-To: <CAEp_U4HaKa2sRu=KoQHYiuBRZDpE9ui2ArmUsKGnok5hS56Fbg@mail.gmail.com>
References: <CAEp_U4HaKa2sRu=KoQHYiuBRZDpE9ui2ArmUsKGnok5hS56Fbg@mail.gmail.com>
Message-ID: <53B3DAEF.2030908@redhat.com>
Done.
On 2.7.2014 01:13, Lincoln Baxter, III wrote:
> If you have created branches in windup/windup that are no longer
> required, please remove them now. We have moved to a "pull request
> required" contribution model, so branches in upstream should no longer
> be required (you should use a branch in your own fork)
>
> I will be performing branch cleanup on Friday, so if there is a branch
> that you do not want deleted, please reply to this thread and let me
> know. Thank you.
>
> Thank you!
> ~Lincoln
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
From lincolnbaxter at gmail.com Wed Jul 2 11:00:52 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 2 Jul 2014 11:00:52 -0400
Subject: [windup-dev] Migration Meeting Minutes - 2014-06-02
Message-ID: <CAEp_U4EcxDSN-n-Ce=ZKuKb03q_Vwe40gvbO-fVGtf7N4g9r6g@mail.gmail.com>
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-02-13.49.html
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-02-13.49.txt
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-02-13.49.log.html
Meeting summary
---------------
* Agenda (lincolnthree, 13:49:48)
* Status reports (lincolnthree, 13:52:44)
* Lincoln is working on implementing Rule metadata - ability to trace
rules to their origin, and retrieve information such as categories,
tags, etc. (lincolnthree, 13:54:25)
* Now using a new pull request workflow (lincolnthree, 14:12:42)
* We've moved to a new git pull request workflow for all non-trivial
contributions. This will facilitate communication and discussion
about changes being made to core code, and provide a digital paper
trail of progress. (lincolnthree, 14:13:29)
* Welcome Matej Briskar, new team member (lincolnthree, 14:13:39)
* We are happy to welcome Matej Briskar to the Migration team. He will
initially be working on porting existing windup 1.x rules to the new
windup 2.x format/api. (lincolnthree, 14:14:22)
* Migration actions (lincolnthree, 14:14:41)
* Github Wiki (ozizka, 14:20:12)
* Github Wiki (lincolnthree, 14:20:47)
* ozizka moved original windup code to windup/windup-legacy repository
(lincolnthree, 14:21:33)
* AGREED: We will use JIRA, IRC, and the Mailing List for design
discussions (lincolnthree, 14:25:24)
* Demos (lincolnthree, 14:26:44)
* We will be demoing/reviewing the reporting/rules metadata work
tomorrow via hangout (lincolnthree, 14:27:04)
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140702/9cc91d90/attachment.html
From itewksbu at redhat.com Sun Jul 6 08:37:45 2014
From: itewksbu at redhat.com (Ian Tewksbury)
Date: Sun, 6 Jul 2014 08:37:45 -0400 (EDT)
Subject: [windup-dev] Could not find artifact
com.tinkerpop:frames:jar:2.6.0-jsight-SNAPSHOT
In-Reply-To: <815231848.2453931.1404650168445.JavaMail.zimbra@redhat.com>
Message-ID: <1342674893.2454023.1404650265749.JavaMail.zimbra@redhat.com>
All,
I just pulled the latest from master and am getting this error, anyone know how to resolve?
Failed to execute goal on project windup-graph-api: Could not resolve dependencies for project org.jboss.windup.graph:windup-graph-api:jar:2.0.0-SNAPSHOT: Could not find artifact com.tinkerpop:frames:jar:2.6.0-jsight-SNAPSHOT in jboss-public-repository-group (http://repository.jboss.org/nexus/content/groups/public/)
Looks like Jesse may have built his own version of com.tinkerpop:frames:jar which Windup now depends on and can not find.
Blue Skies,
~Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140706/f27bdbc3/attachment.html
From itewksbu at redhat.com Sun Jul 6 09:30:17 2014
From: itewksbu at redhat.com (Ian Tewksbury)
Date: Sun, 6 Jul 2014 09:30:17 -0400 (EDT)
Subject: [windup-dev] windup-legacy: Test runner could not locate test class
[org.jboss.windup.test.WindupLegacyWizardTest] in any deployed Addon
In-Reply-To: <540059585.2458385.1404653377363.JavaMail.zimbra@redhat.com>
Message-ID: <1628045910.2458479.1404653417990.JavaMail.zimbra@redhat.com>
All,
When trying to run "mvn clean install" on the Windup Legacy project I am getting the following error. Anyone have a resolution for this?
java.lang.IllegalStateException: Test runner could not locate test class [org.jboss.windup.test.WindupLegacyWizardTest] in any deployed Addon.
at org.jboss.forge.arquillian.ForgeTestMethodExecutor.invoke(ForgeTestMethodExecutor.java:222)
at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
Blue Skies,
~Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140706/ceae591e/attachment.html
From lincolnbaxter at gmail.com Wed Jul 9 10:38:02 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 9 Jul 2014 10:38:02 -0400
Subject: [windup-dev] Could not find artifact
com.tinkerpop:frames:jar:2.6.0-jsight-SNAPSHOT
In-Reply-To: <1342674893.2454023.1404650265749.JavaMail.zimbra@redhat.com>
References: <815231848.2453931.1404650168445.JavaMail.zimbra@redhat.com>
<1342674893.2454023.1404650265749.JavaMail.zimbra@redhat.com>
Message-ID: <CAEp_U4FjDryKW+DMzUh53Ki0Y91dvbhehxgRODiFK-EWB0JCPA@mail.gmail.com>
Hey Ian,
Sorry for the late reply. This artifact should be part of the main reactor
build. Is it not showing up on your end?
~Lincoln
On Sun, Jul 6, 2014 at 8:37 AM, Ian Tewksbury <itewksbu at redhat.com> wrote:
> All,
>
> I just pulled the latest from master and am getting this error, anyone
> know how to resolve?
>
> Failed to execute goal on project windup-graph-api: Could not resolve
> dependencies for project
> org.jboss.windup.graph:windup-graph-api:jar:2.0.0-SNAPSHOT: Could not find
> artifact com.tinkerpop:frames:jar:2.6.0-jsight-SNAPSHOT in
> jboss-public-repository-group (
> http://repository.jboss.org/nexus/content/groups/public/)
>
> Looks like Jesse may have built his own version of
> com.tinkerpop:frames:jar which Windup now depends on and can not find.
>
> Blue Skies,
> ~Ian
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140709/b5891647/attachment.html
From lincolnbaxter at gmail.com Wed Jul 9 10:48:04 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 9 Jul 2014 10:48:04 -0400
Subject: [windup-dev] windup-legacy: Test runner could not locate test
class [org.jboss.windup.test.WindupLegacyWizardTest] in any deployed Addon
In-Reply-To: <1628045910.2458479.1404653417990.JavaMail.zimbra@redhat.com>
References: <540059585.2458385.1404653377363.JavaMail.zimbra@redhat.com>
<1628045910.2458479.1404653417990.JavaMail.zimbra@redhat.com>
Message-ID: <CAEp_U4GjTZCAXNgp9VoFP9dGmNDOV8nkXunP7N7RFbLinpJ6QQ@mail.gmail.com>
Which branch are you on, which repository? Should be on master.
On Sun, Jul 6, 2014 at 9:30 AM, Ian Tewksbury <itewksbu at redhat.com> wrote:
> All,
>
>
> When trying to run "mvn clean install" on the Windup Legacy project I am
> getting the following error. Anyone have a resolution for this?
>
>
> java.lang.IllegalStateException: Test runner could not locate test class
> [org.jboss.windup.test.WindupLegacyWizardTest] in any deployed Addon.
> at
> org.jboss.forge.arquillian.ForgeTestMethodExecutor.invoke(ForgeTestMethodExecutor.java:222)
> at
> org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> ...
>
>
> Blue Skies,
>
> ~Ian
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140709/4232d38b/attachment.html
From lincolnbaxter at gmail.com Wed Jul 9 11:00:02 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 9 Jul 2014 11:00:02 -0400
Subject: [windup-dev] Migration Meeting Minutes - 2014-06-09
Message-ID: <CAEp_U4GOeXpxR0u3tvNYJiziNj_+XFQ7o4go5+LNdafrqc25FQ@mail.gmail.com>
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.html
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.txt
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.log.html
Meeting summary
---------------
* Agenda (lincolnthree, 13:49:54)
* Status Updates (lincolnthree, 13:52:22)
* did a major refactoring yesterday as part of WINDUP-109
(lincolnthree, 13:53:19)
* fixed the impl/api splits ( (lincolnthree, 13:53:25)
* moved most of the model classes into rules-java (lincolnthree,
13:53:43)
* groovy java rules tests are not working for some reason but still
working on that (lincolnthree, 13:54:07)
* I have worked on refactoring the project data model classes (as part
of WINDUP-109) (jsightler, 13:57:41)
* I am also working on refactoring our gremlin query API support as
part of WINDUP-113 (jsightler, 13:58:21)
* Read wikis for Windup (probably mostly deprecated), Gremlin, Frames
and watched all the episodes about jboss windup on youtube.
(mbriskar, 14:03:43)
* added a method to generalize adding criterions ( WINDUP-112 )
(mbriskar, 14:04:21)
* Prepared a prototype rule for java that adds a hint, however it is
done yet. (
https://github.com/mbriskar/windup/commit/0596beb9eb87c0af0e2166b74572549f793d7d04
) (mbriskar, 14:06:53)
* Upcoming Alpha2 release goals (lincolnthree, 14:20:59)
* Goal 1: Prototype rule format in Java/Groovy - (java is complete,
groovy in progress) (lincolnthree, 14:22:11)
* Goal 2: Begin work on rule distribution/installation/auto-upgrade
strategy (looks like this goal is not going to make this release)
(lincolnthree, 14:30:20)
* Goal 3: Begin to find integration points for tools. This is
basically done, but we can't implement until things are a bit more
stable.
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140709/14fb4d6c/attachment-0001.html
From bgeorges at redhat.com Wed Jul 9 21:16:59 2014
From: bgeorges at redhat.com (Bruno Georges)
Date: Thu, 10 Jul 2014 13:16:59 +1200
Subject: [windup-dev] Migration Meeting Minutes - 2014-06-09
In-Reply-To: <CAEp_U4GOeXpxR0u3tvNYJiziNj_+XFQ7o4go5+LNdafrqc25FQ@mail.gmail.com>
References: <CAEp_U4GOeXpxR0u3tvNYJiziNj_+XFQ7o4go5+LNdafrqc25FQ@mail.gmail.com>
Message-ID: <F545D78D-0E4A-4D4D-AEAF-F9B6669D5579@redhat.com>
Thanks Good progress guys!
Quick question: do we have a ?Getting Started? guide to start building rules in Groovy/Java ?
Bruno
On 10/07/2014, at 3:00 am, Lincoln Baxter, III <lincolnbaxter at gmail.com> wrote:
> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.html
>
> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.txt
>
> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.log.html
>
>
> Meeting summary
> ---------------
> * Agenda (lincolnthree, 13:49:54)
>
> * Status Updates (lincolnthree, 13:52:22)
> * did a major refactoring yesterday as part of WINDUP-109 (lincolnthree, 13:53:19)
> * fixed the impl/api splits ( (lincolnthree, 13:53:25)
> * moved most of the model classes into rules-java (lincolnthree,
> 13:53:43)
> * groovy java rules tests are not working for some reason but still
> working on that (lincolnthree, 13:54:07)
> * I have worked on refactoring the project data model classes (as part
> of WINDUP-109) (jsightler, 13:57:41)
> * I am also working on refactoring our gremlin query API support as
> part of WINDUP-113 (jsightler, 13:58:21)
> * Read wikis for Windup (probably mostly deprecated), Gremlin, Frames
> and watched all the episodes about jboss windup on youtube.
> (mbriskar, 14:03:43)
> * added a method to generalize adding criterions ( WINDUP-112 )
> (mbriskar, 14:04:21)
> * Prepared a prototype rule for java that adds a hint, however it is
> done yet. (
> https://github.com/mbriskar/windup/commit/0596beb9eb87c0af0e2166b74572549f793d7d04
> ) (mbriskar, 14:06:53)
>
> * Upcoming Alpha2 release goals (lincolnthree, 14:20:59)
> * Goal 1: Prototype rule format in Java/Groovy - (java is complete,
> groovy in progress) (lincolnthree, 14:22:11)
> * Goal 2: Begin work on rule distribution/installation/auto-upgrade
> strategy (looks like this goal is not going to make this release)
> (lincolnthree, 14:30:20)
> * Goal 3: Begin to find integration points for tools. This is basically done, but we can't implement until things are a bit more stable.
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140710/5f901c10/attachment.html
From lincolnbaxter at gmail.com Thu Jul 10 00:02:44 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Thu, 10 Jul 2014 00:02:44 -0400
Subject: [windup-dev] Migration Meeting Minutes - 2014-06-09
In-Reply-To: <F545D78D-0E4A-4D4D-AEAF-F9B6669D5579@redhat.com>
References: <CAEp_U4GOeXpxR0u3tvNYJiziNj_+XFQ7o4go5+LNdafrqc25FQ@mail.gmail.com>
<F545D78D-0E4A-4D4D-AEAF-F9B6669D5579@redhat.com>
Message-ID: <CAEp_U4Gac1xYYc0LPPjKOspPTw9jdmgVWR4nt3s5uRThLBXe2A@mail.gmail.com>
Hey Bruno, not yet.
We are still working on the APIs as we discover limitations or patterns
that can make things simpler/easier to use. In short, things are still
changing too much.
Here is an example Rule, however. If you read it, you should get the sense
of what it is doing - there are also comments.
https://github.com/windup/windup/blob/master/config/tests/src/test/java/org/jboss/windup/config/JavaExampleRuleProvider.java#L67
On line 96, this is where you would add something that gets render into the
report (which is also currently in progress --> this rule renders the index
page of the report:
https://github.com/windup/windup/blob/master/reporting/impl/src/main/java/org/jboss/windup/reporting/ApplicationReportRenderingRuleProvider.java#L50
The groovy stuff is still very crude and not worth showing yet, but I'm
happy that the Java API keeps getting simpler and more intuitive as we go.
~Lincoln
On Wed, Jul 9, 2014 at 9:16 PM, Bruno Georges <bgeorges at redhat.com> wrote:
> Thanks Good progress guys!
>
> Quick question: do we have a ?Getting Started? guide to start building
> rules in Groovy/Java ?
>
> Bruno
> On 10/07/2014, at 3:00 am, Lincoln Baxter, III <lincolnbaxter at gmail.com>
> wrote:
>
> Minutes:
> http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.html
>
> Minutes (text):
> http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.txt
>
> Log:
> http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.log.html
>
>
> Meeting summary
> ---------------
> * Agenda (lincolnthree, 13:49:54)
>
> * Status Updates (lincolnthree, 13:52:22)
> * did a major refactoring yesterday as part of WINDUP-109 (lincolnthree, 13:53:19)
> * fixed the impl/api splits ( (lincolnthree, 13:53:25)
> * moved most of the model classes into rules-java (lincolnthree,
> 13:53:43)
> * groovy java rules tests are not working for some reason but still
> working on that (lincolnthree, 13:54:07)
> * I have worked on refactoring the project data model classes (as part
> of WINDUP-109) (jsightler, 13:57:41)
> * I am also working on refactoring our gremlin query API support as
> part of WINDUP-113 (jsightler, 13:58:21)
> * Read wikis for Windup (probably mostly deprecated), Gremlin, Frames
> and watched all the episodes about jboss windup on youtube.
> (mbriskar, 14:03:43)
> * added a method to generalize adding criterions ( WINDUP-112 )
> (mbriskar, 14:04:21)
> * Prepared a prototype rule for java that adds a hint, however it is
> done yet. (
> https://github.com/mbriskar/windup/commit/0596beb9eb87c0af0e2166b74572549f793d7d04
> ) (mbriskar, 14:06:53)
>
> * Upcoming Alpha2 release goals (lincolnthree, 14:20:59)
> * Goal 1: Prototype rule format in Java/Groovy - (java is complete,
> groovy in progress) (lincolnthree, 14:22:11)
> * Goal 2: Begin work on rule distribution/installation/auto-upgrade
> strategy (looks like this goal is not going to make this release)
> (lincolnthree, 14:30:20)
>
> * Goal 3: Begin to find integration points for tools. This is basically done, but we can't implement until things are a bit more stable.
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140710/e9a42877/attachment.html
From bgeorges at redhat.com Thu Jul 10 00:29:58 2014
From: bgeorges at redhat.com (Bruno Georges)
Date: Thu, 10 Jul 2014 16:29:58 +1200
Subject: [windup-dev] Migration Meeting Minutes - 2014-06-09
In-Reply-To: <CAEp_U4Gac1xYYc0LPPjKOspPTw9jdmgVWR4nt3s5uRThLBXe2A@mail.gmail.com>
References: <CAEp_U4GOeXpxR0u3tvNYJiziNj_+XFQ7o4go5+LNdafrqc25FQ@mail.gmail.com>
<F545D78D-0E4A-4D4D-AEAF-F9B6669D5579@redhat.com>
<CAEp_U4Gac1xYYc0LPPjKOspPTw9jdmgVWR4nt3s5uRThLBXe2A@mail.gmail.com>
Message-ID: <0CFFC600-520B-4DA1-875A-297BEA523C89@redhat.com>
Thank you Lincoln.
That should suffice for now. Let me know when you get something stable and a guide that can be used by local SAs, I?d like to run some UAT with the folks in the office here.
Cheers,
Bruno
On 10/07/2014, at 4:02 pm, Lincoln Baxter, III <lincolnbaxter at gmail.com> wrote:
> Hey Bruno, not yet.
>
> We are still working on the APIs as we discover limitations or patterns that can make things simpler/easier to use. In short, things are still changing too much.
>
> Here is an example Rule, however. If you read it, you should get the sense of what it is doing - there are also comments.
>
> https://github.com/windup/windup/blob/master/config/tests/src/test/java/org/jboss/windup/config/JavaExampleRuleProvider.java#L67
>
> On line 96, this is where you would add something that gets render into the report (which is also currently in progress --> this rule renders the index page of the report:
>
> https://github.com/windup/windup/blob/master/reporting/impl/src/main/java/org/jboss/windup/reporting/ApplicationReportRenderingRuleProvider.java#L50
>
> The groovy stuff is still very crude and not worth showing yet, but I'm happy that the Java API keeps getting simpler and more intuitive as we go.
>
> ~Lincoln
>
>
> On Wed, Jul 9, 2014 at 9:16 PM, Bruno Georges <bgeorges at redhat.com> wrote:
> Thanks Good progress guys!
>
> Quick question: do we have a ?Getting Started? guide to start building rules in Groovy/Java ?
>
> Bruno
> On 10/07/2014, at 3:00 am, Lincoln Baxter, III <lincolnbaxter at gmail.com> wrote:
>
>> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.html
>>
>> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.txt
>>
>> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-09-13.49.log.html
>>
>>
>> Meeting summary
>> ---------------
>> * Agenda (lincolnthree, 13:49:54)
>>
>> * Status Updates (lincolnthree, 13:52:22)
>> * did a major refactoring yesterday as part of WINDUP-109 (lincolnthree, 13:53:19)
>> * fixed the impl/api splits ( (lincolnthree, 13:53:25)
>> * moved most of the model classes into rules-java (lincolnthree,
>> 13:53:43)
>> * groovy java rules tests are not working for some reason but still
>> working on that (lincolnthree, 13:54:07)
>> * I have worked on refactoring the project data model classes (as part
>> of WINDUP-109) (jsightler, 13:57:41)
>> * I am also working on refactoring our gremlin query API support as
>> part of WINDUP-113 (jsightler, 13:58:21)
>> * Read wikis for Windup (probably mostly deprecated), Gremlin, Frames
>> and watched all the episodes about jboss windup on youtube.
>> (mbriskar, 14:03:43)
>> * added a method to generalize adding criterions ( WINDUP-112 )
>> (mbriskar, 14:04:21)
>> * Prepared a prototype rule for java that adds a hint, however it is
>> done yet. (
>> https://github.com/mbriskar/windup/commit/0596beb9eb87c0af0e2166b74572549f793d7d04
>> ) (mbriskar, 14:06:53)
>>
>> * Upcoming Alpha2 release goals (lincolnthree, 14:20:59)
>> * Goal 1: Prototype rule format in Java/Groovy - (java is complete,
>> groovy in progress) (lincolnthree, 14:22:11)
>> * Goal 2: Begin work on rule distribution/installation/auto-upgrade
>> strategy (looks like this goal is not going to make this release)
>> (lincolnthree, 14:30:20)
>> * Goal 3: Begin to find integration points for tools. This is basically done, but we can't implement until things are a bit more stable.
>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.org
>> "Simpler is better."
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140710/62bbd8ac/attachment-0001.html
From ozizka at redhat.com Tue Jul 15 10:47:34 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 15 Jul 2014 16:47:34 +0200
Subject: [windup-dev] Reporting support in models - common grounds, denotion
Message-ID: <53C53F06.8050103@redhat.com>
Hi,
for reporting, we will need some common grounds in the model classes.
We already had the @Label annotation, but that was removed.
Here's my suggestion:
@Title String - Title of the reported item. Not Name, that is overused
(e.g. all the EE resources will have names).
@Description String / class - longer description.
@Icon("resource/path.png") class - Graphical symbol to make the reports
more appealing.
@FoundBy List<Rule> - rules which found the item.
@Solutions List<Solution> - links to a solutions for given problem -
knowledge base?
@References List<Reference> - links to references for given problem.
URLs to docs.
@Properties Properties / Map<String, String>:
Many resources will have lists of information, e.g. generic
properties, like datasources.
These properties are not known in advance - they are DB specific,
JDBC driver specific, AS specific.
So instead of having a java property for each, it's way better to
have Properties or Map.
Properties won't be present in all models, but will be quite common,
so it should have support in core.
JIRA: https://issues.jboss.org/browse/WINDUP-120
There are few related:
WINDUP-103 Create report data model
WINDUP-109 Refactor model classes to support an abstract project model
WINDUP-117 Update reporting to use the new project meta-model for
producing reports (including blacklist reports)
WINDUP-114 Replace ArchiveModelPointer with a
@ArchiveType(value=".war") annotation on the model classes themselves
Ondra
From ozizka at redhat.com Tue Jul 15 12:22:58 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 15 Jul 2014 18:22:58 +0200
Subject: [windup-dev] Reporting support in models - common grounds,
implementation
In-Reply-To: <53C53F06.8050103@redhat.com>
References: <53C53F06.8050103@redhat.com>
Message-ID: <53C55562.3020903@redhat.com>
Now to the implementation.
Many models, basically all root models, will have (should have)
visuals - @Title @Description @Icon
references - @FoundBy @Solutions @References
@Title, @Decription, and @Icon can be derived from the data contained + annotations data (E.g. EL + values). I have some coding in progress for this.
@FoundBy, @Solutions, and @References will need some identical code in each model. Using inheritance is nonsense in this case.
So instead of adding all that boilerplate code to every model where it's needed (even worse, formatted by the current terrible formatting rules),
I'd create a class containing all these, add it as a member to the model. And instead of @Adjacency, I'd use @ReportItemInfo and a MethodHandler to store it directly to the given vertex, as if the adjacencies where right in there. Or not? Do we want additional intermediate vertex as a wrapper?
RSVP.
Ondra
On 15.7.2014 16:47, Ondrej Zizka wrote:
> Hi,
>
> for reporting, we will need some common grounds in the model classes.
> We already had the @Label annotation, but that was removed.
> Here's my suggestion:
>
> @Title String - Title of the reported item. Not Name, that is overused
> (e.g. all the EE resources will have names).
> @Description String / class - longer description.
> @Icon("resource/path.png") class - Graphical symbol to make the reports
> more appealing.
> @FoundBy List<Rule> - rules which found the item.
> @Solutions List<Solution> - links to a solutions for given problem -
> knowledge base?
> @References List<Reference> - links to references for given problem.
> URLs to docs.
>
> @Properties Properties / Map<String, String>:
> Many resources will have lists of information, e.g. generic
> properties, like datasources.
> These properties are not known in advance - they are DB specific,
> JDBC driver specific, AS specific.
> So instead of having a java property for each, it's way better to
> have Properties or Map.
>
> Properties won't be present in all models, but will be quite common,
> so it should have support in core.
>
> JIRA: https://issues.jboss.org/browse/WINDUP-120
>
> There are few related:
>
> WINDUP-103 Create report data model
> WINDUP-109 Refactor model classes to support an abstract project model
> WINDUP-117 Update reporting to use the new project meta-model for
> producing reports (including blacklist reports)
> WINDUP-114 Replace ArchiveModelPointer with a
> @ArchiveType(value=".war") annotation on the model classes themselves
>
> Ondra
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Tue Jul 15 12:26:51 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 15 Jul 2014 18:26:51 +0200
Subject: [windup-dev] Reporting support in models - common grounds,
implementation
In-Reply-To: <53C55562.3020903@redhat.com>
References: <53C53F06.8050103@redhat.com> <53C55562.3020903@redhat.com>
Message-ID: <53C5564B.100@redhat.com>
Copied to https://issues.jboss.org/browse/WINDUP-120 , let's continue there.
On 15.7.2014 18:22, Ondrej Zizka wrote:
> Now to the implementation.
>
> Many models, basically all root models, will have (should have)
>
> visuals - @Title @Description @Icon
> references - @FoundBy @Solutions @References
>
> @Title, @Decription, and @Icon can be derived from the data contained
> + annotations data (E.g. EL + values). I have some coding in progress
> for this.
>
> @FoundBy, @Solutions, and @References will need some identical code in
> each model. Using inheritance is nonsense in this case.
>
> So instead of adding all that boilerplate code to every model where
> it's needed (even worse, formatted by the current terrible formatting
> rules),
> I'd create a class containing all these, add it as a member to the
> model. And instead of @Adjacency, I'd use @ReportItemInfo and a
> MethodHandler to store it directly to the given vertex, as if the
> adjacencies where right in there. Or not? Do we want additional
> intermediate vertex as a wrapper?
From ozizka at redhat.com Tue Jul 15 12:31:36 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 15 Jul 2014 18:31:36 +0200
Subject: [windup-dev] Windup legacy rules rewriting
Message-ID: <53C55768.40400@redhat.com>
Hi,
just a note on $SUBJ. I may be wrong, but I recall we agreed that the
old rules, since being so monotonous, could have one rule, which would
load the simple data from a static file(s), and one rule which would
execute them. E.g. a simple .csv file with regex, hint, reference. Or
JSON/XML if needed.
Now Matej creates one java rule per each legacy regex.
Is there some change in the previous plan?
Both solutions have obvious advantages, I just want to know what was the
decision.
Thanks,
Ondra
From jsightle at redhat.com Tue Jul 15 13:03:28 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Tue, 15 Jul 2014 13:03:28 -0400
Subject: [windup-dev] Reporting support in models - common grounds,
denotion
In-Reply-To: <53C53F06.8050103@redhat.com>
References: <53C53F06.8050103@redhat.com>
Message-ID: <53C55EE0.8050104@redhat.com>
Hi Ondra,
Have you looked at the reporting code in Windup? We are building data
models for each report that contain much of this information (eg,
title). I am not sure why we would want to use annotations for this
instead of a separate report model?
The @Properties thing is not currently supported by the Graph, though it
may be possible to build something approximating it with @JavaHandlers.
On 07/15/2014 10:47 AM, Ondrej Zizka wrote:
> Hi,
>
> for reporting, we will need some common grounds in the model classes.
> We already had the @Label annotation, but that was removed.
> Here's my suggestion:
>
> @Title String - Title of the reported item. Not Name, that is overused
> (e.g. all the EE resources will have names).
> @Description String / class - longer description.
> @Icon("resource/path.png") class - Graphical symbol to make the reports
> more appealing.
> @FoundBy List<Rule> - rules which found the item.
> @Solutions List<Solution> - links to a solutions for given problem -
> knowledge base?
> @References List<Reference> - links to references for given problem.
> URLs to docs.
>
> @Properties Properties / Map<String, String>:
> Many resources will have lists of information, e.g. generic
> properties, like datasources.
> These properties are not known in advance - they are DB specific,
> JDBC driver specific, AS specific.
> So instead of having a java property for each, it's way better to
> have Properties or Map.
>
> Properties won't be present in all models, but will be quite common,
> so it should have support in core.
>
> JIRA: https://issues.jboss.org/browse/WINDUP-120
>
> There are few related:
>
> WINDUP-103 Create report data model
> WINDUP-109 Refactor model classes to support an abstract project model
> WINDUP-117 Update reporting to use the new project meta-model for
> producing reports (including blacklist reports)
> WINDUP-114 Replace ArchiveModelPointer with a
> @ArchiveType(value=".war") annotation on the model classes themselves
>
> Ondra
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From lincolnbaxter at gmail.com Tue Jul 15 14:10:49 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Tue, 15 Jul 2014 14:10:49 -0400
Subject: [windup-dev] Windup legacy rules rewriting
In-Reply-To: <53C55768.40400@redhat.com>
References: <53C55768.40400@redhat.com>
Message-ID: <CAEp_U4HkG1cwaYhv=fZDBMvYzABusGio5qFn8p7AzFVTteTjKg@mail.gmail.com>
I do remember this discussion, and I think that while it's one possible
solution, it's not really beneficial to have the separated out into
non-java files. In this particular scenario, I do think that writing
multiple rules is probably not what we want, but we do probably want to
keep the data in Java, in the ConfigurationProvider or a closely related
class.
Matej was just doing what he thought we asked him to do, literally port the
rules 1:1. He now understands we meant "port the functionality." :)
On Tue, Jul 15, 2014 at 12:31 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Hi,
>
> just a note on $SUBJ. I may be wrong, but I recall we agreed that the
> old rules, since being so monotonous, could have one rule, which would
> load the simple data from a static file(s), and one rule which would
> execute them. E.g. a simple .csv file with regex, hint, reference. Or
> JSON/XML if needed.
>
> Now Matej creates one java rule per each legacy regex.
> Is there some change in the previous plan?
> Both solutions have obvious advantages, I just want to know what was the
> decision.
>
> Thanks,
> Ondra
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140715/a53d23e8/attachment.html
From bgeorges at redhat.com Tue Jul 15 17:35:25 2014
From: bgeorges at redhat.com (Bruno Georges)
Date: Wed, 16 Jul 2014 09:35:25 +1200
Subject: [windup-dev] Windup legacy rules rewriting
In-Reply-To: <CAEp_U4HkG1cwaYhv=fZDBMvYzABusGio5qFn8p7AzFVTteTjKg@mail.gmail.com>
References: <53C55768.40400@redhat.com>
<CAEp_U4HkG1cwaYhv=fZDBMvYzABusGio5qFn8p7AzFVTteTjKg@mail.gmail.com>
Message-ID: <4F40A9B4-CC15-40B9-BF36-C17829FC5BCF@redhat.com>
Thinking out loud, having the ability to externalise rules is a big plus imo, I recall my years writing simplybusiness.co.uk 's Quotation engine, having rules in Java was not ideal at all.
Hence, I am still a proponent of this approach. It has many advantages, productivity/testability are 2 of them.
my 2 cents.
Bruno
On 16/07/2014, at 6:10 am, Lincoln Baxter, III <lincolnbaxter at gmail.com> wrote:
> I do remember this discussion, and I think that while it's one possible solution, it's not really beneficial to have the separated out into non-java files. In this particular scenario, I do think that writing multiple rules is probably not what we want, but we do probably want to keep the data in Java, in the ConfigurationProvider or a closely related class.
>
> Matej was just doing what he thought we asked him to do, literally port the rules 1:1. He now understands we meant "port the functionality." :)
>
>
> On Tue, Jul 15, 2014 at 12:31 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Hi,
>
> just a note on $SUBJ. I may be wrong, but I recall we agreed that the
> old rules, since being so monotonous, could have one rule, which would
> load the simple data from a static file(s), and one rule which would
> execute them. E.g. a simple .csv file with regex, hint, reference. Or
> JSON/XML if needed.
>
> Now Matej creates one java rule per each legacy regex.
> Is there some change in the previous plan?
> Both solutions have obvious advantages, I just want to know what was the
> decision.
>
> Thanks,
> Ondra
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140716/e420a043/attachment-0001.html
From lincolnbaxter at gmail.com Wed Jul 16 04:27:07 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 16 Jul 2014 04:27:07 -0400
Subject: [windup-dev] Windup legacy rules rewriting
In-Reply-To: <4F40A9B4-CC15-40B9-BF36-C17829FC5BCF@redhat.com>
References: <53C55768.40400@redhat.com>
<CAEp_U4HkG1cwaYhv=fZDBMvYzABusGio5qFn8p7AzFVTteTjKg@mail.gmail.com>
<4F40A9B4-CC15-40B9-BF36-C17829FC5BCF@redhat.com>
Message-ID: <CAEp_U4HjBUCaacm_ptfy6F7N=qKGKT5YeqZsA=tLNLwjr7atrw@mail.gmail.com>
Hey Bruno,
Yeah, we definitely plan on externalizing this, but I'd rather not just
create a separate data format just to keep this stuff out of java (I'd
rather implement it properly via the Groovy simplified rule stuff, which
this is a prerequisite for.
My only point here is that I see little difference between putting strings
in a .CSV file and in a Java file considering we'll be exposing this in
groovy anyway :)
~Lincoln
On Tue, Jul 15, 2014 at 5:35 PM, Bruno Georges <bgeorges at redhat.com> wrote:
> Thinking out loud, having the ability to externalise rules is a big plus
> imo, I recall my years writing simplybusiness.co.uk 's Quotation engine,
> having rules in Java was not ideal at all.
> Hence, I am still a proponent of this approach. It has many advantages,
> productivity/testability are 2 of them.
>
> my 2 cents.
>
> Bruno
>
> On 16/07/2014, at 6:10 am, Lincoln Baxter, III <lincolnbaxter at gmail.com>
> wrote:
>
> I do remember this discussion, and I think that while it's one possible
> solution, it's not really beneficial to have the separated out into
> non-java files. In this particular scenario, I do think that writing
> multiple rules is probably not what we want, but we do probably want to
> keep the data in Java, in the ConfigurationProvider or a closely related
> class.
>
> Matej was just doing what he thought we asked him to do, literally port
> the rules 1:1. He now understands we meant "port the functionality." :)
>
>
> On Tue, Jul 15, 2014 at 12:31 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
>
>> Hi,
>>
>> just a note on $SUBJ. I may be wrong, but I recall we agreed that the
>> old rules, since being so monotonous, could have one rule, which would
>> load the simple data from a static file(s), and one rule which would
>> execute them. E.g. a simple .csv file with regex, hint, reference. Or
>> JSON/XML if needed.
>>
>> Now Matej creates one java rule per each legacy regex.
>> Is there some change in the previous plan?
>> Both solutions have obvious advantages, I just want to know what was the
>> decision.
>>
>> Thanks,
>> Ondra
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140716/52a12b45/attachment.html
From ozizka at redhat.com Wed Jul 16 09:57:14 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 16 Jul 2014 15:57:14 +0200
Subject: [windup-dev] Reporting support in models - common grounds,
denotion
In-Reply-To: <53C55EE0.8050104@redhat.com>
References: <53C53F06.8050103@redhat.com> <53C55EE0.8050104@redhat.com>
Message-ID: <53C684BA.8050601@redhat.com>
On 15.7.2014 19:03, Jess Sightler wrote:
> Hi Ondra,
>
> Have you looked at the reporting code in Windup? We are building data
> models for each report that contain much of this information (eg,
> title). I am not sure why we would want to use annotations for this
> instead of a separate report model?
Let me reverse the question - why would we duplicate the models? Many of
them will be very simple. Annotations is ideal, short, user friendly,
solution.
We discussed this at the F2F, and agreed that
- it's way better not to duplicate structures where not necessary;
- we will have additional structure in the graph for reporting, but
will only link the standard models where possible.
Ondra
>
> The @Properties thing is not currently supported by the Graph, though it
> may be possible to build something approximating it with @JavaHandlers.
>
> On 07/15/2014 10:47 AM, Ondrej Zizka wrote:
>> Hi,
>>
>> for reporting, we will need some common grounds in the model classes.
>> We already had the @Label annotation, but that was removed.
>> Here's my suggestion:
>>
>> @Title String - Title of the reported item. Not Name, that is overused
>> (e.g. all the EE resources will have names).
>> @Description String / class - longer description.
>> @Icon("resource/path.png") class - Graphical symbol to make the reports
>> more appealing.
>> @FoundBy List<Rule> - rules which found the item.
>> @Solutions List<Solution> - links to a solutions for given problem -
>> knowledge base?
>> @References List<Reference> - links to references for given problem.
>> URLs to docs.
>>
>> @Properties Properties / Map<String, String>:
>> Many resources will have lists of information, e.g. generic
>> properties, like datasources.
>> These properties are not known in advance - they are DB specific,
>> JDBC driver specific, AS specific.
>> So instead of having a java property for each, it's way better to
>> have Properties or Map.
>>
>> Properties won't be present in all models, but will be quite common,
>> so it should have support in core.
>>
>> JIRA: https://issues.jboss.org/browse/WINDUP-120
>>
>> There are few related:
>>
>> WINDUP-103 Create report data model
>> WINDUP-109 Refactor model classes to support an abstract project model
>> WINDUP-117 Update reporting to use the new project meta-model for
>> producing reports (including blacklist reports)
>> WINDUP-114 Replace ArchiveModelPointer with a
>> @ArchiveType(value=".war") annotation on the model classes themselves
>>
>> Ondra
>>
>>
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Wed Jul 16 10:07:03 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 16 Jul 2014 16:07:03 +0200
Subject: [windup-dev] Reporting support in models - common grounds,
denotion
In-Reply-To: <53C55EE0.8050104@redhat.com>
References: <53C53F06.8050103@redhat.com> <53C55EE0.8050104@redhat.com>
Message-ID: <53C68707.2050405@redhat.com>
On 15.7.2014 19:03, Jess Sightler wrote:
> Hi Ondra,
>
> Have you looked at the reporting code in Windup? We are building data
> models for each report that contain much of this information (eg,
> title).
Looking at it now, as I need some shared structures - user input, rules,
deployments etc.
Ondra
From lincolnbaxter at gmail.com Wed Jul 16 13:14:43 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 16 Jul 2014 13:14:43 -0400
Subject: [windup-dev] Windup meeting minutes: 2014-06-16
Message-ID: <CAEp_U4F_qreDp7VbLX2h6q_Xz0XfogbGHifiN1ZzqLuMfPLAMA@mail.gmail.com>
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-16-13.50.html
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-16-13.50.txt
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-16-13.50.log.html
Meeting summary
---------------
* Agenda (lincolnthree, 13:50:44)
* Status updates (lincolnthree, 13:50:55)
* Alpha2 release checkin (lincolnthree, 13:51:29)
* Progress checkin (lincolnthree, 13:51:48)
* Reporting (lincolnthree, 13:53:33)
* Externalizing legacy rules data (lincolnthree, 13:53:41)
* Documentation (lincolnthree, 13:54:14)
* LINK: irc://irc.freenode.net:6667/#info Status updates
(lincolnthree, 13:56:17)
* Status Updates (lincolnthree, 13:56:24)
* Migration-base models and first rules are already merged (mbriskar,
13:57:53)
* Pull request for migrating java legacy rules is already there
(mbriskar, 13:58:09)
* there is only need to migrate XML rules and the migration should be
done (mbriskar, 13:59:34)
* Did some cleanup of the codebase last week (lincolnthree, 14:00:55)
* Helped with cleanup up the JavaClassModel relationships, and did a
big refactor to clean up the remaining DAO designs (DAOs are now all
*Services) (lincolnthree, 14:01:57)
* working next on proxies issue, then after that, writing tests for
existing features and probably getting sucked into more refactoring
(lincolnthree, 14:05:50)
* Proxies issue - FORGE-1877 (lincolnthree, 14:06:13)
* I have been working on WINDUP-117 (jsightler, 14:06:56)
* The goal here is to produce an initial report based upon the
classifications placed in the graph by the blacklists (jsightler,
14:07:31)
* I also added the ability to store Adjacent Vertices as a Map via an
annotation on the Frame (jsightler, 14:08:44)
* Ondra was on PTO. (ozizka, 14:11:22)
* Then resumed work on Reporting. Which I will discuss in topic.
(ozizka, 14:11:49)
* Also cleaning the wiki. (ozizka, 14:12:06)
* Alpha2 release checkin (lincolnthree, 14:13:38)
* ACTION: Lincoln will add JIRA issues to the Alpha2 release, which
will occur when those issues are complete (lincolnthree, 14:22:05)
* Progress checkpoint (lincolnthree, 14:23:18)
* Java rules API - implemented, working well (lincolnthree, 14:24:04)
* Tagging/categorizing rules - supported, not extremely simple but
working (lincolnthree, 14:24:36)
* Data model able to represent migration domain - in progress,
blacklist, project, java class, maven project, and report models are
in place - still improving (lincolnthree, 14:25:16)
* APIs for use in tools, known but not implemented yet. waiting on
more functionality (lincolnthree, 14:25:45)
* Reporting infrastructure is in place, working on building
classification/blacklist report to demonstrate API usage
(lincolnthree, 14:27:33)
* Performance under observation, will need to do some optimization
before releasing (lincolnthree, 14:28:21)
* Reporting (lincolnthree, 14:28:44)
* LINK:
http://ondrazizka.github.io/jboss-migration/reports/0.10.4/MigrationReport-2013-06-11_09-39-23.xml.html
(ozizka, 14:36:23)
* LINK:
https://github.com/OndraZizka/jboss-migration/blob/master/engine/src/main/java/org/jboss/loom/migrators/mail/MailServiceBean.java
(ozizka, 14:40:07)
* LINK: https://issues.jboss.org/browse/WINDUP-91 (ozizka, 16:21:27)
* Reports discussion ran super long. Last topics will wait until next
week. (lincolnthree, 16:44:59)
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140716/678668ad/attachment.html
From ozizka at redhat.com Mon Jul 21 19:03:55 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 22 Jul 2014 01:03:55 +0200
Subject: [windup-dev] RuleModel et al.
Message-ID: <53CD9C5B.1070404@redhat.com>
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
From ozizka at redhat.com Mon Jul 21 19:08:15 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 22 Jul 2014 01:08:15 +0200
Subject: [windup-dev] RuleModel et al.
In-Reply-To: <53CD9C5B.1070404@redhat.com>
References: <53CD9C5B.1070404@redhat.com>
Message-ID: <53CD9D5F.3080904@redhat.com>
> Current ID is not guaranteed to be the same over runs.
> Current ID has no namespaces.
>
Striking these two - I looked at wrong getId().
From jsightle at redhat.com Mon Jul 21 20:40:05 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Mon, 21 Jul 2014 20:40:05 -0400
Subject: [windup-dev] RuleModel et al.
In-Reply-To: <53CD9C5B.1070404@redhat.com>
References: <53CD9C5B.1070404@redhat.com>
Message-ID: <53CDB2E5.9060204@redhat.com>
I'm not opposed to this idea... except that I don't know what a
"RuleModel" would actually contain, other than the ID.
What are you proposing it to contain?
On 07/21/2014 07:03 PM, Ondrej Zizka wrote:
> 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
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Mon Jul 21 20:54:45 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 22 Jul 2014 02:54:45 +0200
Subject: [windup-dev] Legacy Classifications and Decorators in separate rules
Message-ID: <53CDB655.4010002@redhat.com>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140722/333b03a1/attachment.html
From ozizka at redhat.com Mon Jul 21 20:59:24 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 22 Jul 2014 02:59:24 +0200
Subject: [windup-dev] RuleModel et al.
In-Reply-To: <53CDB2E5.9060204@redhat.com>
References: <53CD9C5B.1070404@redhat.com> <53CDB2E5.9060204@redhat.com>
Message-ID: <53CDB76C.7030306@redhat.com>
So far, an ID and a reference to the Ruleset. The ruleset then would
probably have further info, like, version etc.
https://github.com/OndraZizka/windup/blob/3940b146f811ab6e5fff1cb6c6def7179a33a467/reporting/api/src/main/java/org/jboss/windup/reporting/model/RuleModel.java
Anyway, even if it was just an ID, OOP principles suggest to encapsulate
that ID to a type. My experience agrees. I may be wrong though.
Ondra
On 22.7.2014 02:40, Jess Sightler wrote:
> I'm not opposed to this idea... except that I don't know what a
> "RuleModel" would actually contain, other than the ID.
>
> What are you proposing it to contain?
>
> On 07/21/2014 07:03 PM, Ondrej Zizka wrote:
>> 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
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Mon Jul 21 21:07:07 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 22 Jul 2014 03:07:07 +0200
Subject: [windup-dev] RuleModel et al.
In-Reply-To: <53CDB76C.7030306@redhat.com>
References: <53CD9C5B.1070404@redhat.com> <53CDB2E5.9060204@redhat.com>
<53CDB76C.7030306@redhat.com>
Message-ID: <53CDB93B.9010602@redhat.com>
Forgot to mention the context of my thoughts.
I am not sure what are the plans for integration of Eclipse, Windup,
Migration site and Customer Portal; but it's obvious that the "Rule"
will be present everywhere. So I think we will need some common class
with basic Rule info, which will be part of the API.
Not sure if it all should be the same class, maybe not. But at least for
Eclipse module, having a RuleModel would be beneficial, since we will
have some automatic converter for the Eclipse <--> Windup API, and we
might want to show more about the rule in Eclipse than just a cryptic ID.
In Windup itself, we might look up the rule in some Map, but what's the
advantage against simply adding the reference to anything added by a
rule? This could be even automatized later, simply by intercepting the
calls to services somehow.
Ondra
On 22.7.2014 02:59, Ondrej Zizka wrote:
> So far, an ID and a reference to the Ruleset. The ruleset then would
> probably have further info, like, version etc.
>
> https://github.com/OndraZizka/windup/blob/3940b146f811ab6e5fff1cb6c6def7179a33a467/reporting/api/src/main/java/org/jboss/windup/reporting/model/RuleModel.java
>
> Anyway, even if it was just an ID, OOP principles suggest to encapsulate
> that ID to a type. My experience agrees. I may be wrong though.
>
> Ondra
>
>
> On 22.7.2014 02:40, Jess Sightler wrote:
>> I'm not opposed to this idea... except that I don't know what a
>> "RuleModel" would actually contain, other than the ID.
>>
>> What are you proposing it to contain?
>>
>> On 07/21/2014 07:03 PM, Ondrej Zizka wrote:
>>> 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
>>>
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Tue Jul 22 09:15:57 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 22 Jul 2014 15:15:57 +0200
Subject: [windup-dev] Packages - remove .rules.?
org.jboss.windup.rules.apps/server -> .windup.apps/server
Message-ID: <53CE640D.4020700@redhat.com>
Hi,
we will likely only have apps and server rule groups.
How about removing the .rules. part? Just like we did with maven structure.
Just an idea, but to be considered before we release.
Ondra
From jsightle at redhat.com Tue Jul 22 10:09:45 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Tue, 22 Jul 2014 10:09:45 -0400
Subject: [windup-dev] RuleModel et al.
In-Reply-To: <53CDB76C.7030306@redhat.com>
References: <53CD9C5B.1070404@redhat.com> <53CDB2E5.9060204@redhat.com>
<53CDB76C.7030306@redhat.com>
Message-ID: <53CE70A9.6090403@redhat.com>
Oh, I see... if we are going to do this, I could see it having a few things:
1. RuleID - A string uniquely identifying the rule
2. Rule Version - The version of the addon containing the rule
3. RulePhase - The phase during which the rule was run
I don't think that this belongs in reporting, though. I am also not sure
how easy it would be to automate the population of these fields, though
it might be possible with some tweaks to frames.
On 07/21/2014 08:59 PM, Ondrej Zizka wrote:
> So far, an ID and a reference to the Ruleset. The ruleset then would
> probably have further info, like, version etc.
>
> https://github.com/OndraZizka/windup/blob/3940b146f811ab6e5fff1cb6c6def7179a33a467/reporting/api/src/main/java/org/jboss/windup/reporting/model/RuleModel.java
>
> Anyway, even if it was just an ID, OOP principles suggest to encapsulate
> that ID to a type. My experience agrees. I may be wrong though.
>
> Ondra
>
>
> On 22.7.2014 02:40, Jess Sightler wrote:
>> I'm not opposed to this idea... except that I don't know what a
>> "RuleModel" would actually contain, other than the ID.
>>
>> What are you proposing it to contain?
>>
>> On 07/21/2014 07:03 PM, Ondrej Zizka wrote:
>>> 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
>>>
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Tue Jul 22 10:10:29 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 22 Jul 2014 16:10:29 +0200
Subject: [windup-dev] Jira component "Core"
Message-ID: <53CE70D5.1040500@redhat.com>
Could we please add $subj?
Thanks
From lincolnbaxter at gmail.com Tue Jul 22 10:24:43 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Tue, 22 Jul 2014 10:24:43 -0400
Subject: [windup-dev] Jira component "Core"
In-Reply-To: <53CE70D5.1040500@redhat.com>
References: <53CE70D5.1040500@redhat.com>
Message-ID: <CAEp_U4FxCmpPZ_coEL+mnnUNajvRHc2pTn+Q8NRhMgzo8P_Uqw@mail.gmail.com>
Core seems a bit general. What are you trying to categorize?
On Jul 22, 2014 10:10 AM, "Ondrej Zizka" <ozizka at redhat.com> wrote:
> Could we please add $subj?
>
> Thanks
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140722/90d062db/attachment.html
From lincolnbaxter at gmail.com Tue Jul 22 10:57:03 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Tue, 22 Jul 2014 10:57:03 -0400
Subject: [windup-dev] RuleModel et al.
In-Reply-To: <53CE70A9.6090403@redhat.com>
References: <53CD9C5B.1070404@redhat.com> <53CDB2E5.9060204@redhat.com>
<53CDB76C.7030306@redhat.com> <53CE70A9.6090403@redhat.com>
Message-ID: <CAEp_U4HiwHm436i39CveBVLdE4t8ubnczesOfjqeOsN4phdceg@mail.gmail.com>
The rule executor (RuleSubset) could actually handle doing this I think.
For each rule it executes, set the ID, the version, and the phase in the
graph (and possibly also a stringification of what the rule consists of)
On Tue, Jul 22, 2014 at 10:09 AM, Jess Sightler <jsightle at redhat.com> wrote:
> Oh, I see... if we are going to do this, I could see it having a few
> things:
>
> 1. RuleID - A string uniquely identifying the rule
> 2. Rule Version - The version of the addon containing the rule
> 3. RulePhase - The phase during which the rule was run
>
> I don't think that this belongs in reporting, though. I am also not sure
> how easy it would be to automate the population of these fields, though
> it might be possible with some tweaks to frames.
>
> On 07/21/2014 08:59 PM, Ondrej Zizka wrote:
> > So far, an ID and a reference to the Ruleset. The ruleset then would
> > probably have further info, like, version etc.
> >
> >
> https://github.com/OndraZizka/windup/blob/3940b146f811ab6e5fff1cb6c6def7179a33a467/reporting/api/src/main/java/org/jboss/windup/reporting/model/RuleModel.java
> >
> > Anyway, even if it was just an ID, OOP principles suggest to encapsulate
> > that ID to a type. My experience agrees. I may be wrong though.
> >
> > Ondra
> >
> >
> > On 22.7.2014 02:40, Jess Sightler wrote:
> >> I'm not opposed to this idea... except that I don't know what a
> >> "RuleModel" would actually contain, other than the ID.
> >>
> >> What are you proposing it to contain?
> >>
> >> On 07/21/2014 07:03 PM, Ondrej Zizka wrote:
> >>> 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
> >>>
> >>> _______________________________________________
> >>> windup-dev mailing list
> >>> windup-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/windup-dev
> >> _______________________________________________
> >> windup-dev mailing list
> >> windup-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/windup-dev
> > _______________________________________________
> > windup-dev mailing list
> > windup-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/windup-dev
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140722/455bf008/attachment-0001.html
From jsightle at redhat.com Tue Jul 22 11:30:35 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Tue, 22 Jul 2014 11:30:35 -0400
Subject: [windup-dev] RuleModel et al.
In-Reply-To: <CAEp_U4HiwHm436i39CveBVLdE4t8ubnczesOfjqeOsN4phdceg@mail.gmail.com>
References: <53CD9C5B.1070404@redhat.com>
<53CDB2E5.9060204@redhat.com> <53CDB76C.7030306@redhat.com>
<53CE70A9.6090403@redhat.com>
<CAEp_U4HiwHm436i39CveBVLdE4t8ubnczesOfjqeOsN4phdceg@mail.gmail.com>
Message-ID: <53CE839B.5040700@redhat.com>
But how does it know which vertices were created (or modified) by that rule?
On 07/22/2014 10:57 AM, Lincoln Baxter, III wrote:
> The rule executor (RuleSubset) could actually handle doing this I
> think. For each rule it executes, set the ID, the version, and the
> phase in the graph (and possibly also a stringification of what the
> rule consists of)
>
>
> On Tue, Jul 22, 2014 at 10:09 AM, Jess Sightler <jsightle at redhat.com
> <mailto:jsightle at redhat.com>> wrote:
>
> Oh, I see... if we are going to do this, I could see it having a
> few things:
>
> 1. RuleID - A string uniquely identifying the rule
> 2. Rule Version - The version of the addon containing the rule
> 3. RulePhase - The phase during which the rule was run
>
> I don't think that this belongs in reporting, though. I am also
> not sure
> how easy it would be to automate the population of these fields,
> though
> it might be possible with some tweaks to frames.
>
> On 07/21/2014 08:59 PM, Ondrej Zizka wrote:
> > So far, an ID and a reference to the Ruleset. The ruleset then would
> > probably have further info, like, version etc.
> >
> >
> https://github.com/OndraZizka/windup/blob/3940b146f811ab6e5fff1cb6c6def7179a33a467/reporting/api/src/main/java/org/jboss/windup/reporting/model/RuleModel.java
> >
> > Anyway, even if it was just an ID, OOP principles suggest to
> encapsulate
> > that ID to a type. My experience agrees. I may be wrong though.
> >
> > Ondra
> >
> >
> > On 22.7.2014 02:40, Jess Sightler wrote:
> >> I'm not opposed to this idea... except that I don't know what a
> >> "RuleModel" would actually contain, other than the ID.
> >>
> >> What are you proposing it to contain?
> >>
> >> On 07/21/2014 07:03 PM, Ondrej Zizka wrote:
> >>> 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
> >>>
> >>> _______________________________________________
> >>> windup-dev mailing list
> >>> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/windup-dev
> >> _______________________________________________
> >> windup-dev mailing list
> >> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/windup-dev
> > _______________________________________________
> > windup-dev mailing list
> > windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/windup-dev
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140722/758ebd04/attachment.html
From ozizka at redhat.com Tue Jul 22 14:28:04 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 22 Jul 2014 20:28:04 +0200
Subject: [windup-dev] RuleModel et al.
In-Reply-To: <53CE839B.5040700@redhat.com>
References: <53CD9C5B.1070404@redhat.com> <53CDB2E5.9060204@redhat.com> <53CDB76C.7030306@redhat.com> <53CE70A9.6090403@redhat.com> <CAEp_U4HiwHm436i39CveBVLdE4t8ubnczesOfjqeOsN4phdceg@mail.gmail.com>
<53CE839B.5040700@redhat.com>
Message-ID: <53CEAD34.2070202@redhat.com>
1) A reference to the rule being executed could be made accessible from
a context.
2) Some layer above Frames could catch any creation/alteration of
vertices and link them.
Haven't seen Frames guts, perhaps not doable easily at the moment.
On 22.7.2014 17:30, Jess Sightler wrote:
> But how does it know which vertices were created (or modified) by that
> rule?
>
> On 07/22/2014 10:57 AM, Lincoln Baxter, III wrote:
>> The rule executor (RuleSubset) could actually handle doing this I
>> think. For each rule it executes, set the ID, the version, and the
>> phase in the graph (and possibly also a stringification of what the
>> rule consists of)
>>
>>
>> On Tue, Jul 22, 2014 at 10:09 AM, Jess Sightler <jsightle at redhat.com
>> <mailto:jsightle at redhat.com>> wrote:
>>
>> Oh, I see... if we are going to do this, I could see it having a
>> few things:
>>
>> 1. RuleID - A string uniquely identifying the rule
>> 2. Rule Version - The version of the addon containing the rule
>> 3. RulePhase - The phase during which the rule was run
>>
>> I don't think that this belongs in reporting, though. I am also
>> not sure
>> how easy it would be to automate the population of these fields,
>> though
>> it might be possible with some tweaks to frames.
>>
>> On 07/21/2014 08:59 PM, Ondrej Zizka wrote:
>> > So far, an ID and a reference to the Ruleset. The ruleset then
>> would
>> > probably have further info, like, version etc.
>> >
>> >
>> https://github.com/OndraZizka/windup/blob/3940b146f811ab6e5fff1cb6c6def7179a33a467/reporting/api/src/main/java/org/jboss/windup/reporting/model/RuleModel.java
>> >
>> > Anyway, even if it was just an ID, OOP principles suggest to
>> encapsulate
>> > that ID to a type. My experience agrees. I may be wrong though.
>> >
>> > Ondra
>> >
>> >
>> > On 22.7.2014 02:40, Jess Sightler wrote:
>> >> I'm not opposed to this idea... except that I don't know what a
>> >> "RuleModel" would actually contain, other than the ID.
>> >>
>> >> What are you proposing it to contain?
>> >>
>> >> On 07/21/2014 07:03 PM, Ondrej Zizka wrote:
>> >>> 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
>> >>>
>> >>> _______________________________________________
>> >>> windup-dev mailing list
>> >>> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>> >>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> >> _______________________________________________
>> >> windup-dev mailing list
>> >> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>> >> https://lists.jboss.org/mailman/listinfo/windup-dev
>> > _______________________________________________
>> > windup-dev mailing list
>> > windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.org
>> "Simpler is better."
>>
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140722/b5540e2f/attachment.html
From jsightle at redhat.com Tue Jul 22 18:09:47 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Tue, 22 Jul 2014 18:09:47 -0400
Subject: [windup-dev] RuleModel et al.
In-Reply-To: <53CEAD34.2070202@redhat.com>
References: <53CD9C5B.1070404@redhat.com> <53CDB2E5.9060204@redhat.com> <53CDB76C.7030306@redhat.com> <53CE70A9.6090403@redhat.com> <CAEp_U4HiwHm436i39CveBVLdE4t8ubnczesOfjqeOsN4phdceg@mail.gmail.com> <53CE839B.5040700@redhat.com>
<53CEAD34.2070202@redhat.com>
Message-ID: <53CEE12B.4050206@redhat.com>
I think doing it with some layer above frames would be hard. Doing it
within a frames module might not be, though. I haven't really dug into
how easy it is to extensively monitor Vertex changes this way.
On 07/22/2014 02:28 PM, Ondrej Zizka wrote:
> 1) A reference to the rule being executed could be made accessible
> from a context.
> 2) Some layer above Frames could catch any creation/alteration of
> vertices and link them.
>
> Haven't seen Frames guts, perhaps not doable easily at the moment.
>
>
> On 22.7.2014 17:30, Jess Sightler wrote:
>> But how does it know which vertices were created (or modified) by
>> that rule?
>>
>> On 07/22/2014 10:57 AM, Lincoln Baxter, III wrote:
>>> The rule executor (RuleSubset) could actually handle doing this I
>>> think. For each rule it executes, set the ID, the version, and the
>>> phase in the graph (and possibly also a stringification of what the
>>> rule consists of)
>>>
>>>
>>> On Tue, Jul 22, 2014 at 10:09 AM, Jess Sightler <jsightle at redhat.com
>>> <mailto:jsightle at redhat.com>> wrote:
>>>
>>> Oh, I see... if we are going to do this, I could see it having a
>>> few things:
>>>
>>> 1. RuleID - A string uniquely identifying the rule
>>> 2. Rule Version - The version of the addon containing the rule
>>> 3. RulePhase - The phase during which the rule was run
>>>
>>> I don't think that this belongs in reporting, though. I am also
>>> not sure
>>> how easy it would be to automate the population of these fields,
>>> though
>>> it might be possible with some tweaks to frames.
>>>
>>> On 07/21/2014 08:59 PM, Ondrej Zizka wrote:
>>> > So far, an ID and a reference to the Ruleset. The ruleset then
>>> would
>>> > probably have further info, like, version etc.
>>> >
>>> >
>>> https://github.com/OndraZizka/windup/blob/3940b146f811ab6e5fff1cb6c6def7179a33a467/reporting/api/src/main/java/org/jboss/windup/reporting/model/RuleModel.java
>>> >
>>> > Anyway, even if it was just an ID, OOP principles suggest to
>>> encapsulate
>>> > that ID to a type. My experience agrees. I may be wrong though.
>>> >
>>> > Ondra
>>> >
>>> >
>>> > On 22.7.2014 02:40, Jess Sightler wrote:
>>> >> I'm not opposed to this idea... except that I don't know what a
>>> >> "RuleModel" would actually contain, other than the ID.
>>> >>
>>> >> What are you proposing it to contain?
>>> >>
>>> >> On 07/21/2014 07:03 PM, Ondrej Zizka wrote:
>>> >>> 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
>>> >>>
>>> >>> _______________________________________________
>>> >>> windup-dev mailing list
>>> >>> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>>> >>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>> >> _______________________________________________
>>> >> windup-dev mailing list
>>> >> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>>> >> https://lists.jboss.org/mailman/listinfo/windup-dev
>>> > _______________________________________________
>>> > windup-dev mailing list
>>> > windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>>> > https://lists.jboss.org/mailman/listinfo/windup-dev
>>>
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>
>>>
>>>
>>>
>>> --
>>> Lincoln Baxter, III
>>> http://ocpsoft.org
>>> "Simpler is better."
>>>
>>>
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>>
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140722/a79030c0/attachment-0001.html
From bdavis at redhat.com Tue Jul 22 19:45:41 2014
From: bdavis at redhat.com (Brad Davis)
Date: Tue, 22 Jul 2014 19:45:41 -0400 (EDT)
Subject: [windup-dev] RuleModel et al.
In-Reply-To: <53CEAD34.2070202@redhat.com>
References: <53CD9C5B.1070404@redhat.com> <53CDB2E5.9060204@redhat.com>
<53CDB76C.7030306@redhat.com> <53CE70A9.6090403@redhat.com>
<CAEp_U4HiwHm436i39CveBVLdE4t8ubnczesOfjqeOsN4phdceg@mail.gmail.com>
<53CE839B.5040700@redhat.com> <53CEAD34.2070202@redhat.com>
Message-ID: <B2C53D10-D47B-49C7-93C3-D05DF5B3B7D1@redhat.com>
There are graph listeners already I'm pretty sure.
Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c:980.226.7865 |http://www.redhat.com
> On Jul 22, 2014, at 2:28 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
>
> 1) A reference to the rule being executed could be made accessible from a context.
> 2) Some layer above Frames could catch any creation/alteration of vertices and link them.
>
> Haven't seen Frames guts, perhaps not doable easily at the moment.
>
>
>> On 22.7.2014 17:30, Jess Sightler wrote:
>> But how does it know which vertices were created (or modified) by that rule?
>>
>>> On 07/22/2014 10:57 AM, Lincoln Baxter, III wrote:
>>> The rule executor (RuleSubset) could actually handle doing this I think. For each rule it executes, set the ID, the version, and the phase in the graph (and possibly also a stringification of what the rule consists of)
>>>
>>>
>>>> On Tue, Jul 22, 2014 at 10:09 AM, Jess Sightler <jsightle at redhat.com> wrote:
>>>> Oh, I see... if we are going to do this, I could see it having a few things:
>>>>
>>>> 1. RuleID - A string uniquely identifying the rule
>>>> 2. Rule Version - The version of the addon containing the rule
>>>> 3. RulePhase - The phase during which the rule was run
>>>>
>>>> I don't think that this belongs in reporting, though. I am also not sure
>>>> how easy it would be to automate the population of these fields, though
>>>> it might be possible with some tweaks to frames.
>>>>
>>>> On 07/21/2014 08:59 PM, Ondrej Zizka wrote:
>>>> > So far, an ID and a reference to the Ruleset. The ruleset then would
>>>> > probably have further info, like, version etc.
>>>> >
>>>> > https://github.com/OndraZizka/windup/blob/3940b146f811ab6e5fff1cb6c6def7179a33a467/reporting/api/src/main/java/org/jboss/windup/reporting/model/RuleModel.java
>>>> >
>>>> > Anyway, even if it was just an ID, OOP principles suggest to encapsulate
>>>> > that ID to a type. My experience agrees. I may be wrong though.
>>>> >
>>>> > Ondra
>>>> >
>>>> >
>>>> > On 22.7.2014 02:40, Jess Sightler wrote:
>>>> >> I'm not opposed to this idea... except that I don't know what a
>>>> >> "RuleModel" would actually contain, other than the ID.
>>>> >>
>>>> >> What are you proposing it to contain?
>>>> >>
>>>> >> On 07/21/2014 07:03 PM, Ondrej Zizka wrote:
>>>> >>> 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
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> windup-dev mailing list
>>>> >>> windup-dev at lists.jboss.org
>>>> >>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>> >> _______________________________________________
>>>> >> windup-dev mailing list
>>>> >> windup-dev at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>> > _______________________________________________
>>>> > windup-dev mailing list
>>>> > windup-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/windup-dev
>>>>
>>>> _______________________________________________
>>>> windup-dev mailing list
>>>> windup-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>
>>>
>>>
>>> --
>>> Lincoln Baxter, III
>>> http://ocpsoft.org
>>> "Simpler is better."
>>>
>>>
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>>
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140722/7589fff2/attachment.html
From ozizka at redhat.com Tue Jul 22 22:13:49 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 23 Jul 2014 04:13:49 +0200
Subject: [windup-dev] Maven deps again
Message-ID: <53CF1A5D.4000005@redhat.com>
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
From ozizka at redhat.com Wed Jul 23 07:20:42 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 23 Jul 2014 13:20:42 +0200
Subject: [windup-dev] Rename one of 2 perform()s?
Message-ID: <53CF9A8A.9060806@redhat.com>
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
From lincolnbaxter at gmail.com Wed Jul 23 10:12:19 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 23 Jul 2014 10:12:19 -0400
Subject: [windup-dev] Rename one of 2 perform()s?
In-Reply-To: <53CF9A8A.9060806@redhat.com>
References: <53CF9A8A.9060806@redhat.com>
Message-ID: <CAEp_U4E5D62wjcLttuMwzC6CYOwi6mNTi2tXQrSQXZPr2p0BoQ@mail.gmail.com>
Please see comments in the issue you submitted:
https://github.com/ocpsoft/rewrite/issues/179
This is intentional and I think it makes sense.
On Wed, Jul 23, 2014 at 7:20 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
> 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
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140723/db38e2fc/attachment-0001.html
From lincolnbaxter at gmail.com Wed Jul 23 10:13:05 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 23 Jul 2014 10:13:05 -0400
Subject: [windup-dev] Packages - remove .rules.?
org.jboss.windup.rules.apps/server -> .windup.apps/server
In-Reply-To: <53CE640D.4020700@redhat.com>
References: <53CE640D.4020700@redhat.com>
Message-ID: <CAEp_U4GRwLMsysh+9eZ18p1z3kBT8r1vxfL4c_g1gGNUSfeb3Q@mail.gmail.com>
Yeah. This is something that I think will be good to do as part of a larger
naming review before we release the Final/GA.
On Tue, Jul 22, 2014 at 9:15 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Hi,
>
> we will likely only have apps and server rule groups.
> How about removing the .rules. part? Just like we did with maven structure.
> Just an idea, but to be considered before we release.
>
> Ondra
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140723/23f42648/attachment.html
From lincolnbaxter at gmail.com Wed Jul 23 10:57:02 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 23 Jul 2014 10:57:02 -0400
Subject: [windup-dev] Windup Meeting Minutes: 2014-06-23
Message-ID: <CAEp_U4HGkO9VOs73KSyOTQOuPuJyzoMzbhWnJekAUeLO+6Hbkg@mail.gmail.com>
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-23-13.50.html
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-23-13.50.txt
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-07-23-13.50.log.html
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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140723/323de4d0/attachment.html
From lincolnbaxter at gmail.com Wed Jul 23 18:14:46 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 23 Jul 2014 18:14:46 -0400
Subject: [windup-dev] Legacy Classifications and Decorators in separate
rules
In-Reply-To: <53CDB655.4010002@redhat.com>
References: <53CDB655.4010002@redhat.com>
Message-ID: <CAEp_U4FHYt5=6AtJnU0xg6mERco+QB=ENO7T+9t0OgTfcPV7ag@mail.gmail.com>
Hey Ondra, I generally agree with your summary. This was a miscommunication
and I was trying to understand exactly what Matej meant. We got it resolved.
On Mon, Jul 21, 2014 at 8:54 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> 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
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140723/415dd70b/attachment.html
From jsightle at redhat.com Fri Jul 25 10:13:57 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Fri, 25 Jul 2014 10:13:57 -0400
Subject: [windup-dev] RuleModel et al.
In-Reply-To: <B2C53D10-D47B-49C7-93C3-D05DF5B3B7D1@redhat.com>
References: <53CD9C5B.1070404@redhat.com>
<53CDB2E5.9060204@redhat.com> <53CDB76C.7030306@redhat.com>
<53CE70A9.6090403@redhat.com> <CAEp_U4HiwHm436i39CveBVLdE4t8ubnczesOfjqeOsN4phdceg@mail.gmail.com> <53CE839B.5040700@redhat.com>
<53CEAD34.2070202@redhat.com>
<B2C53D10-D47B-49C7-93C3-D05DF5B3B7D1@redhat.com>
Message-ID: <53D26625.6090500@redhat.com>
It does look like there is an EventGraph that could make this easier:
http://www.tinkerpop.com/docs/javadocs/blueprints/2.0.0/com/tinkerpop/blueprints/util/wrappers/event/EventGraph.html
I have filed a JIRA for us to enable this:
https://issues.jboss.org/browse/WINDUP-149
On 07/22/2014 07:45 PM, Brad Davis wrote:
> There are graph listeners already I'm pretty sure.
>
> Brad Davis
> Red Hat Consulting
> Email: bdavis at redhat.com <mailto:bdavis at redhat.com> | c:980.226.7865
> <tel:980.226.7865> |http://www.redhat.com <http://www.redhat.com/>
>
> On Jul 22, 2014, at 2:28 PM, Ondrej Zizka <ozizka at redhat.com
> <mailto:ozizka at redhat.com>> wrote:
>
>> 1) A reference to the rule being executed could be made accessible
>> from a context.
>> 2) Some layer above Frames could catch any creation/alteration of
>> vertices and link them.
>>
>> Haven't seen Frames guts, perhaps not doable easily at the moment.
>>
>>
>> On 22.7.2014 17:30, Jess Sightler wrote:
>>> But how does it know which vertices were created (or modified) by
>>> that rule?
>>>
>>> On 07/22/2014 10:57 AM, Lincoln Baxter, III wrote:
>>>> The rule executor (RuleSubset) could actually handle doing this I
>>>> think. For each rule it executes, set the ID, the version, and the
>>>> phase in the graph (and possibly also a stringification of what the
>>>> rule consists of)
>>>>
>>>>
>>>> On Tue, Jul 22, 2014 at 10:09 AM, Jess Sightler
>>>> <jsightle at redhat.com <mailto:jsightle at redhat.com>> wrote:
>>>>
>>>> Oh, I see... if we are going to do this, I could see it having
>>>> a few things:
>>>>
>>>> 1. RuleID - A string uniquely identifying the rule
>>>> 2. Rule Version - The version of the addon containing the rule
>>>> 3. RulePhase - The phase during which the rule was run
>>>>
>>>> I don't think that this belongs in reporting, though. I am also
>>>> not sure
>>>> how easy it would be to automate the population of these
>>>> fields, though
>>>> it might be possible with some tweaks to frames.
>>>>
>>>> On 07/21/2014 08:59 PM, Ondrej Zizka wrote:
>>>> > So far, an ID and a reference to the Ruleset. The ruleset
>>>> then would
>>>> > probably have further info, like, version etc.
>>>> >
>>>> >
>>>> https://github.com/OndraZizka/windup/blob/3940b146f811ab6e5fff1cb6c6def7179a33a467/reporting/api/src/main/java/org/jboss/windup/reporting/model/RuleModel.java
>>>> >
>>>> > Anyway, even if it was just an ID, OOP principles suggest to
>>>> encapsulate
>>>> > that ID to a type. My experience agrees. I may be wrong though.
>>>> >
>>>> > Ondra
>>>> >
>>>> >
>>>> > On 22.7.2014 02:40, Jess Sightler wrote:
>>>> >> I'm not opposed to this idea... except that I don't know what a
>>>> >> "RuleModel" would actually contain, other than the ID.
>>>> >>
>>>> >> What are you proposing it to contain?
>>>> >>
>>>> >> On 07/21/2014 07:03 PM, Ondrej Zizka wrote:
>>>> >>> 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
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> windup-dev mailing list
>>>> >>> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>>>> >>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>> >> _______________________________________________
>>>> >> windup-dev mailing list
>>>> >> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>>>> >> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>> > _______________________________________________
>>>> > windup-dev mailing list
>>>> > windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>>>> > https://lists.jboss.org/mailman/listinfo/windup-dev
>>>>
>>>> _______________________________________________
>>>> windup-dev mailing list
>>>> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lincoln Baxter, III
>>>> http://ocpsoft.org
>>>> "Simpler is better."
>>>>
>>>>
>>>> _______________________________________________
>>>> windup-dev mailing list
>>>> windup-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140725/42612d35/attachment-0001.html
From ozizka at redhat.com Fri Jul 25 13:26:30 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 25 Jul 2014 19:26:30 +0200
Subject: [windup-dev] Iteration using Java's for?
Message-ID: <53D29346.3090601@redhat.com>
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
From ozizka at redhat.com Fri Jul 25 13:28:31 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 25 Jul 2014 19:28:31 +0200
Subject: [windup-dev] Iteration using Java's for?
In-Reply-To: <53D29346.3090601@redhat.com>
References: <53D29346.3090601@redhat.com>
Message-ID: <53D293BF.4050603@redhat.com>
Subquestions:
Do we want to / can we restrict the Groovy DSL syntax anyhow?
Will we aim for alternative XML-based rules which would translate to the
API?
On 25.7.2014 19:26, Ondrej Zizka wrote:
> 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
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Fri Jul 25 14:02:06 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 25 Jul 2014 20:02:06 +0200
Subject: [windup-dev] Where to store intermediate data?
Message-ID: <53D29B9E.9070305@redhat.com>
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
From bdavis at redhat.com Fri Jul 25 14:09:57 2014
From: bdavis at redhat.com (Brad Davis)
Date: Fri, 25 Jul 2014 14:09:57 -0400 (EDT)
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <53D29B9E.9070305@redhat.com>
References: <53D29B9E.9070305@redhat.com>
Message-ID: <1593995573.1873719.1406311797137.JavaMail.zimbra@redhat.com>
The Titan implementation already provides caching. When you say a Map like API, you mean to access the data on the nodes?
>From an intermediate data perspective, you can always get the underlying vertex from the Framed Vertex, and then write to it like a Map (Key, Value pair).
Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
----- Original Message -----
From: "Ondrej Zizka" <ozizka at redhat.com>
To: "Windup-dev List" <windup-dev at lists.jboss.org>
Sent: Friday, July 25, 2014 2:02:06 PM
Subject: [windup-dev] Where to store intermediate data?
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
_______________________________________________
windup-dev mailing list
windup-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
From bdavis at redhat.com Fri Jul 25 14:11:30 2014
From: bdavis at redhat.com (Brad Davis)
Date: Fri, 25 Jul 2014 14:11:30 -0400 (EDT)
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <1593995573.1873719.1406311797137.JavaMail.zimbra@redhat.com>
References: <53D29B9E.9070305@redhat.com>
<1593995573.1873719.1406311797137.JavaMail.zimbra@redhat.com>
Message-ID: <1598486400.1874269.1406311890930.JavaMail.zimbra@redhat.com>
Alternative to adding data to the graph vertex directly, you could create a intermediate vertex that has a reference to another vertex you are referring to.
IntermediateMapVertex -> SomeOtherVertex
Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
----- Original Message -----
From: "Brad Davis" <bdavis at redhat.com>
To: "Windup-dev List" <windup-dev at lists.jboss.org>
Sent: Friday, July 25, 2014 2:09:57 PM
Subject: Re: [windup-dev] Where to store intermediate data?
The Titan implementation already provides caching. When you say a Map like API, you mean to access the data on the nodes?
>From an intermediate data perspective, you can always get the underlying vertex from the Framed Vertex, and then write to it like a Map (Key, Value pair).
Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
----- Original Message -----
From: "Ondrej Zizka" <ozizka at redhat.com>
To: "Windup-dev List" <windup-dev at lists.jboss.org>
Sent: Friday, July 25, 2014 2:02:06 PM
Subject: [windup-dev] Where to store intermediate data?
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
_______________________________________________
windup-dev mailing list
windup-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Fri Jul 25 14:21:47 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 25 Jul 2014 20:21:47 +0200
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <1598486400.1874269.1406311890930.JavaMail.zimbra@redhat.com>
References: <53D29B9E.9070305@redhat.com> <1593995573.1873719.1406311797137.JavaMail.zimbra@redhat.com>
<1598486400.1874269.1406311890930.JavaMail.zimbra@redhat.com>
Message-ID: <53D2A03B.7030307@redhat.com>
Right, but Lincoln doesn't want the intermediate data in the graph, if I
understand him correctly.
That's why I am looking for some Map in our Java data structures.
Ondra
On 25.7.2014 20:11, Brad Davis wrote:
> Alternative to adding data to the graph vertex directly, you could create a intermediate vertex that has a reference to another vertex you are referring to.
>
> IntermediateMapVertex -> SomeOtherVertex
>
> Brad Davis
> Red Hat Consulting
> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>
>
> ----- Original Message -----
> From: "Brad Davis" <bdavis at redhat.com>
> To: "Windup-dev List" <windup-dev at lists.jboss.org>
> Sent: Friday, July 25, 2014 2:09:57 PM
> Subject: Re: [windup-dev] Where to store intermediate data?
>
> The Titan implementation already provides caching. When you say a Map like API, you mean to access the data on the nodes?
>
> >From an intermediate data perspective, you can always get the underlying vertex from the Framed Vertex, and then write to it like a Map (Key, Value pair).
>
> Brad Davis
> Red Hat Consulting
> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>
>
> ----- Original Message -----
> From: "Ondrej Zizka" <ozizka at redhat.com>
> To: "Windup-dev List" <windup-dev at lists.jboss.org>
> Sent: Friday, July 25, 2014 2:02:06 PM
> Subject: [windup-dev] Where to store intermediate data?
>
> 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
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From bdavis at redhat.com Fri Jul 25 14:39:57 2014
From: bdavis at redhat.com (Brad Davis)
Date: Fri, 25 Jul 2014 14:39:57 -0400 (EDT)
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <53D2A03B.7030307@redhat.com>
References: <53D29B9E.9070305@redhat.com>
<1593995573.1873719.1406311797137.JavaMail.zimbra@redhat.com>
<1598486400.1874269.1406311890930.JavaMail.zimbra@redhat.com>
<53D2A03B.7030307@redhat.com>
Message-ID: <1849535334.1893943.1406313597970.JavaMail.zimbra@redhat.com>
Oh gotcha. So you mean like a map to pass data along during the execution of a rule itself?
Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
----- Original Message -----
From: "Ondrej Zizka" <ozizka at redhat.com>
To: windup-dev at lists.jboss.org
Sent: Friday, July 25, 2014 2:21:47 PM
Subject: Re: [windup-dev] Where to store intermediate data?
Right, but Lincoln doesn't want the intermediate data in the graph, if I
understand him correctly.
That's why I am looking for some Map in our Java data structures.
Ondra
On 25.7.2014 20:11, Brad Davis wrote:
> Alternative to adding data to the graph vertex directly, you could create a intermediate vertex that has a reference to another vertex you are referring to.
>
> IntermediateMapVertex -> SomeOtherVertex
>
> Brad Davis
> Red Hat Consulting
> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>
>
> ----- Original Message -----
> From: "Brad Davis" <bdavis at redhat.com>
> To: "Windup-dev List" <windup-dev at lists.jboss.org>
> Sent: Friday, July 25, 2014 2:09:57 PM
> Subject: Re: [windup-dev] Where to store intermediate data?
>
> The Titan implementation already provides caching. When you say a Map like API, you mean to access the data on the nodes?
>
> >From an intermediate data perspective, you can always get the underlying vertex from the Framed Vertex, and then write to it like a Map (Key, Value pair).
>
> Brad Davis
> Red Hat Consulting
> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>
>
> ----- Original Message -----
> From: "Ondrej Zizka" <ozizka at redhat.com>
> To: "Windup-dev List" <windup-dev at lists.jboss.org>
> Sent: Friday, July 25, 2014 2:02:06 PM
> Subject: [windup-dev] Where to store intermediate data?
>
> 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
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Fri Jul 25 14:44:51 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 25 Jul 2014 20:44:51 +0200
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <1849535334.1893943.1406313597970.JavaMail.zimbra@redhat.com>
References: <53D29B9E.9070305@redhat.com> <1593995573.1873719.1406311797137.JavaMail.zimbra@redhat.com> <1598486400.1874269.1406311890930.JavaMail.zimbra@redhat.com> <53D2A03B.7030307@redhat.com>
<1849535334.1893943.1406313597970.JavaMail.zimbra@redhat.com>
Message-ID: <53D2A5A3.5060708@redhat.com>
A rule, or perhaps during whole execution.
Actually those are 2 different things.
Currently, I need whole runtime scope - for Model metadata.
And also, I was thinking about a rule computing a sum of e.g. JMS queues
capacities (or anything such).
That would need an iteration, and within iteration, we have VarStack,
but that's only for WindupVertexFrames, so I was thinking what the user
has to store data like this, which are not to be reported.
Ondra
On 25.7.2014 20:39, Brad Davis wrote:
> Oh gotcha. So you mean like a map to pass data along during the execution of a rule itself?
>
> Brad Davis
> Red Hat Consulting
> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>
>
> ----- Original Message -----
> From: "Ondrej Zizka" <ozizka at redhat.com>
> To: windup-dev at lists.jboss.org
> Sent: Friday, July 25, 2014 2:21:47 PM
> Subject: Re: [windup-dev] Where to store intermediate data?
>
> Right, but Lincoln doesn't want the intermediate data in the graph, if I
> understand him correctly.
> That's why I am looking for some Map in our Java data structures.
>
> Ondra
>
>
>
> On 25.7.2014 20:11, Brad Davis wrote:
>> Alternative to adding data to the graph vertex directly, you could create a intermediate vertex that has a reference to another vertex you are referring to.
>>
>> IntermediateMapVertex -> SomeOtherVertex
>>
>> Brad Davis
>> Red Hat Consulting
>> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>>
>>
>> ----- Original Message -----
>> From: "Brad Davis" <bdavis at redhat.com>
>> To: "Windup-dev List" <windup-dev at lists.jboss.org>
>> Sent: Friday, July 25, 2014 2:09:57 PM
>> Subject: Re: [windup-dev] Where to store intermediate data?
>>
>> The Titan implementation already provides caching. When you say a Map like API, you mean to access the data on the nodes?
>>
>> >From an intermediate data perspective, you can always get the underlying vertex from the Framed Vertex, and then write to it like a Map (Key, Value pair).
>>
>> Brad Davis
>> Red Hat Consulting
>> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>>
>>
>> ----- Original Message -----
>> From: "Ondrej Zizka" <ozizka at redhat.com>
>> To: "Windup-dev List" <windup-dev at lists.jboss.org>
>> Sent: Friday, July 25, 2014 2:02:06 PM
>> Subject: [windup-dev] Where to store intermediate data?
>>
>> 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
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From bdavis at redhat.com Fri Jul 25 14:55:26 2014
From: bdavis at redhat.com (Brad Davis)
Date: Fri, 25 Jul 2014 14:55:26 -0400 (EDT)
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <53D2A5A3.5060708@redhat.com>
References: <53D29B9E.9070305@redhat.com>
<1593995573.1873719.1406311797137.JavaMail.zimbra@redhat.com>
<1598486400.1874269.1406311890930.JavaMail.zimbra@redhat.com>
<53D2A03B.7030307@redhat.com>
<1849535334.1893943.1406313597970.JavaMail.zimbra@redhat.com>
<53D2A5A3.5060708@redhat.com>
Message-ID: <1835217983.1901947.1406314526230.JavaMail.zimbra@redhat.com>
If you want something to keep data around for the whole run, it makes sense to put it to the graph. The idea for the graph is to keep data out of memory full time, because if the data is being kept around a long time, you want to have the graph purge that from memory to keep your heap tidy. Otherwise, like Windup 1, large applications or apps with a lot of meta information in memory can cause a out of memory exception.
So, to me it makes sense to have an in-memory context for the execution of a rule. But, if you are having data beyond one rule that you plan to keep around to reason on potentially by other rules, it would get put to the graph.
Example:
You have an XML file ...
You have a rule that says "when i have the root node /example,"
- extract the xml's name to a temporary variable
And a sub-rule that says "for each node //somevalue"
- extract the //somevalue/@somexpath locally for the context
And an outcome for each of those //somevalue nodes: Add in the Hint to the somevalue's XML Line position in the XML of: "This is an example of $somevalue within the XML named $xmlName"
So the hint itself would be added to the Graph since you want that to be around for a long time after this rule runs... but the variable of the XML file's name, and specifically the local context when it is looping (for each) on some XPath Expression would be in memory and not written to the graph. Make sense?
Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
----- Original Message -----
From: "Ondrej Zizka" <ozizka at redhat.com>
To: windup-dev at lists.jboss.org
Sent: Friday, July 25, 2014 2:44:51 PM
Subject: Re: [windup-dev] Where to store intermediate data?
A rule, or perhaps during whole execution.
Actually those are 2 different things.
Currently, I need whole runtime scope - for Model metadata.
And also, I was thinking about a rule computing a sum of e.g. JMS queues
capacities (or anything such).
That would need an iteration, and within iteration, we have VarStack,
but that's only for WindupVertexFrames, so I was thinking what the user
has to store data like this, which are not to be reported.
Ondra
On 25.7.2014 20:39, Brad Davis wrote:
> Oh gotcha. So you mean like a map to pass data along during the execution of a rule itself?
>
> Brad Davis
> Red Hat Consulting
> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>
>
> ----- Original Message -----
> From: "Ondrej Zizka" <ozizka at redhat.com>
> To: windup-dev at lists.jboss.org
> Sent: Friday, July 25, 2014 2:21:47 PM
> Subject: Re: [windup-dev] Where to store intermediate data?
>
> Right, but Lincoln doesn't want the intermediate data in the graph, if I
> understand him correctly.
> That's why I am looking for some Map in our Java data structures.
>
> Ondra
>
>
>
> On 25.7.2014 20:11, Brad Davis wrote:
>> Alternative to adding data to the graph vertex directly, you could create a intermediate vertex that has a reference to another vertex you are referring to.
>>
>> IntermediateMapVertex -> SomeOtherVertex
>>
>> Brad Davis
>> Red Hat Consulting
>> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>>
>>
>> ----- Original Message -----
>> From: "Brad Davis" <bdavis at redhat.com>
>> To: "Windup-dev List" <windup-dev at lists.jboss.org>
>> Sent: Friday, July 25, 2014 2:09:57 PM
>> Subject: Re: [windup-dev] Where to store intermediate data?
>>
>> The Titan implementation already provides caching. When you say a Map like API, you mean to access the data on the nodes?
>>
>> >From an intermediate data perspective, you can always get the underlying vertex from the Framed Vertex, and then write to it like a Map (Key, Value pair).
>>
>> Brad Davis
>> Red Hat Consulting
>> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>>
>>
>> ----- Original Message -----
>> From: "Ondrej Zizka" <ozizka at redhat.com>
>> To: "Windup-dev List" <windup-dev at lists.jboss.org>
>> Sent: Friday, July 25, 2014 2:02:06 PM
>> Subject: [windup-dev] Where to store intermediate data?
>>
>> 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
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
From lincolnbaxter at gmail.com Fri Jul 25 15:25:02 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 25 Jul 2014 15:25:02 -0400
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <53D29B9E.9070305@redhat.com>
References: <53D29B9E.9070305@redhat.com>
Message-ID: <CAEp_U4H3ieCjvkYLjpSbzNxgwy9oM8QCs2k3ZRmN2-9=LQW0mw@mail.gmail.com>
Hey Ondra,
The model Metadata is already available via the GraphTypeRegistry/etc. I
would recommend that if there is some other view or format that you need
for this data, then consider extending the existing API to support your use
case - e.g. Return a map view, for example.
~Lincoln
On Fri, Jul 25, 2014 at 2:02 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> 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
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140725/f7becb4a/attachment.html
From lincolnbaxter at gmail.com Fri Jul 25 15:26:15 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 25 Jul 2014 15:26:15 -0400
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <CAEp_U4H3ieCjvkYLjpSbzNxgwy9oM8QCs2k3ZRmN2-9=LQW0mw@mail.gmail.com>
References: <53D29B9E.9070305@redhat.com>
<CAEp_U4H3ieCjvkYLjpSbzNxgwy9oM8QCs2k3ZRmN2-9=LQW0mw@mail.gmail.com>
Message-ID: <CAEp_U4Hp_ZwWTG-CZ0d=T00ic7iZqJ+Y+gGq13WCBWpdxvF=Vw@mail.gmail.com>
As I was trying to communicate yesterday, I'm not sure why you need another
storage location for this when we already have the data stored in the
GraphTypeManager :) I *am* open to ideas on this, but I need to see a
technical reason to duplicate the info.
On Fri, Jul 25, 2014 at 3:25 PM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:
> Hey Ondra,
>
> The model Metadata is already available via the GraphTypeRegistry/etc. I
> would recommend that if there is some other view or format that you need
> for this data, then consider extending the existing API to support your use
> case - e.g. Return a map view, for example.
>
> ~Lincoln
>
>
> On Fri, Jul 25, 2014 at 2:02 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
>
>> 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
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140725/6beca819/attachment.html
From lincolnbaxter at gmail.com Fri Jul 25 15:39:29 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 25 Jul 2014 15:39:29 -0400
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <53D2A03B.7030307@redhat.com>
References: <53D29B9E.9070305@redhat.com>
<1593995573.1873719.1406311797137.JavaMail.zimbra@redhat.com>
<1598486400.1874269.1406311890930.JavaMail.zimbra@redhat.com>
<53D2A03B.7030307@redhat.com>
Message-ID: <CAEp_U4FfNGKdJMXJpcNP0pzhcOT7nLzvGDqzOnJJbkOGzz3yZA@mail.gmail.com>
Ah, also, I didn't say I don't want intermediate data in the graph :) That
is an over-generalization. I said I don't think *this* data belongs in the
graph. We do want to be storing the *right* data in the graph. And we need
to be careful about what that data is and where and how it is stored.
On Fri, Jul 25, 2014 at 2:21 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Right, but Lincoln doesn't want the intermediate data in the graph, if I
> understand him correctly.
> That's why I am looking for some Map in our Java data structures.
>
> Ondra
>
>
>
> On 25.7.2014 20:11, Brad Davis wrote:
> > Alternative to adding data to the graph vertex directly, you could
> create a intermediate vertex that has a reference to another vertex you are
> referring to.
> >
> > IntermediateMapVertex -> SomeOtherVertex
> >
> > Brad Davis
> > Red Hat Consulting
> > Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
> >
> >
> > ----- Original Message -----
> > From: "Brad Davis" <bdavis at redhat.com>
> > To: "Windup-dev List" <windup-dev at lists.jboss.org>
> > Sent: Friday, July 25, 2014 2:09:57 PM
> > Subject: Re: [windup-dev] Where to store intermediate data?
> >
> > The Titan implementation already provides caching. When you say a Map
> like API, you mean to access the data on the nodes?
> >
> > >From an intermediate data perspective, you can always get the
> underlying vertex from the Framed Vertex, and then write to it like a Map
> (Key, Value pair).
> >
> > Brad Davis
> > Red Hat Consulting
> > Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
> >
> >
> > ----- Original Message -----
> > From: "Ondrej Zizka" <ozizka at redhat.com>
> > To: "Windup-dev List" <windup-dev at lists.jboss.org>
> > Sent: Friday, July 25, 2014 2:02:06 PM
> > Subject: [windup-dev] Where to store intermediate data?
> >
> > 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
> > _______________________________________________
> > windup-dev mailing list
> > windup-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/windup-dev
> > _______________________________________________
> > windup-dev mailing list
> > windup-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/windup-dev
> > _______________________________________________
> > windup-dev mailing list
> > windup-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/windup-dev
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140725/d6743556/attachment.html
From lincolnbaxter at gmail.com Fri Jul 25 15:40:33 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 25 Jul 2014 15:40:33 -0400
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <CAEp_U4FfNGKdJMXJpcNP0pzhcOT7nLzvGDqzOnJJbkOGzz3yZA@mail.gmail.com>
References: <53D29B9E.9070305@redhat.com>
<1593995573.1873719.1406311797137.JavaMail.zimbra@redhat.com>
<1598486400.1874269.1406311890930.JavaMail.zimbra@redhat.com>
<53D2A03B.7030307@redhat.com>
<CAEp_U4FfNGKdJMXJpcNP0pzhcOT7nLzvGDqzOnJJbkOGzz3yZA@mail.gmail.com>
Message-ID: <CAEp_U4FdZ_fSmCUNcwmg4P6h43e4TRYXCOe2d7-VyfYXfAVk+g@mail.gmail.com>
Additionally, if you're looking for a context. Use
GraphRewrite.getRewriteContext() ... it is a map-like structure, but I
don't think we'll need to use it much so consider the various factors
carefully (and discuss if you are unsure) when thinking about putting
information there.
On Fri, Jul 25, 2014 at 3:39 PM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:
> Ah, also, I didn't say I don't want intermediate data in the graph :) That
> is an over-generalization. I said I don't think *this* data belongs in the
> graph. We do want to be storing the *right* data in the graph. And we need
> to be careful about what that data is and where and how it is stored.
>
>
> On Fri, Jul 25, 2014 at 2:21 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
>
>> Right, but Lincoln doesn't want the intermediate data in the graph, if I
>> understand him correctly.
>> That's why I am looking for some Map in our Java data structures.
>>
>> Ondra
>>
>>
>>
>> On 25.7.2014 20:11, Brad Davis wrote:
>> > Alternative to adding data to the graph vertex directly, you could
>> create a intermediate vertex that has a reference to another vertex you are
>> referring to.
>> >
>> > IntermediateMapVertex -> SomeOtherVertex
>> >
>> > Brad Davis
>> > Red Hat Consulting
>> > Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>> >
>> >
>> > ----- Original Message -----
>> > From: "Brad Davis" <bdavis at redhat.com>
>> > To: "Windup-dev List" <windup-dev at lists.jboss.org>
>> > Sent: Friday, July 25, 2014 2:09:57 PM
>> > Subject: Re: [windup-dev] Where to store intermediate data?
>> >
>> > The Titan implementation already provides caching. When you say a Map
>> like API, you mean to access the data on the nodes?
>> >
>> > >From an intermediate data perspective, you can always get the
>> underlying vertex from the Framed Vertex, and then write to it like a Map
>> (Key, Value pair).
>> >
>> > Brad Davis
>> > Red Hat Consulting
>> > Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>> >
>> >
>> > ----- Original Message -----
>> > From: "Ondrej Zizka" <ozizka at redhat.com>
>> > To: "Windup-dev List" <windup-dev at lists.jboss.org>
>> > Sent: Friday, July 25, 2014 2:02:06 PM
>> > Subject: [windup-dev] Where to store intermediate data?
>> >
>> > 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
>> > _______________________________________________
>> > windup-dev mailing list
>> > windup-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/windup-dev
>> > _______________________________________________
>> > windup-dev mailing list
>> > windup-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/windup-dev
>> > _______________________________________________
>> > windup-dev mailing list
>> > windup-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140725/48d222a8/attachment-0001.html
From lincolnbaxter at gmail.com Fri Jul 25 15:40:49 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 25 Jul 2014 15:40:49 -0400
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <CAEp_U4FdZ_fSmCUNcwmg4P6h43e4TRYXCOe2d7-VyfYXfAVk+g@mail.gmail.com>
References: <53D29B9E.9070305@redhat.com>
<1593995573.1873719.1406311797137.JavaMail.zimbra@redhat.com>
<1598486400.1874269.1406311890930.JavaMail.zimbra@redhat.com>
<53D2A03B.7030307@redhat.com>
<CAEp_U4FfNGKdJMXJpcNP0pzhcOT7nLzvGDqzOnJJbkOGzz3yZA@mail.gmail.com>
<CAEp_U4FdZ_fSmCUNcwmg4P6h43e4TRYXCOe2d7-VyfYXfAVk+g@mail.gmail.com>
Message-ID: <CAEp_U4HJRKrEvR1SvJbF_bNBUWazDbTqWQ5RcDDtKcu6p4Dcew@mail.gmail.com>
I am signing off for PTO. Not supposed to be working today. See you all in
a week :)
On Fri, Jul 25, 2014 at 3:40 PM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:
> Additionally, if you're looking for a context. Use
> GraphRewrite.getRewriteContext() ... it is a map-like structure, but I
> don't think we'll need to use it much so consider the various factors
> carefully (and discuss if you are unsure) when thinking about putting
> information there.
>
>
> On Fri, Jul 25, 2014 at 3:39 PM, Lincoln Baxter, III <
> lincolnbaxter at gmail.com> wrote:
>
>> Ah, also, I didn't say I don't want intermediate data in the graph :)
>> That is an over-generalization. I said I don't think *this* data belongs in
>> the graph. We do want to be storing the *right* data in the graph. And we
>> need to be careful about what that data is and where and how it is stored.
>>
>>
>> On Fri, Jul 25, 2014 at 2:21 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
>>
>>> Right, but Lincoln doesn't want the intermediate data in the graph, if I
>>> understand him correctly.
>>> That's why I am looking for some Map in our Java data structures.
>>>
>>> Ondra
>>>
>>>
>>>
>>> On 25.7.2014 20:11, Brad Davis wrote:
>>> > Alternative to adding data to the graph vertex directly, you could
>>> create a intermediate vertex that has a reference to another vertex you are
>>> referring to.
>>> >
>>> > IntermediateMapVertex -> SomeOtherVertex
>>> >
>>> > Brad Davis
>>> > Red Hat Consulting
>>> > Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>>> >
>>> >
>>> > ----- Original Message -----
>>> > From: "Brad Davis" <bdavis at redhat.com>
>>> > To: "Windup-dev List" <windup-dev at lists.jboss.org>
>>> > Sent: Friday, July 25, 2014 2:09:57 PM
>>> > Subject: Re: [windup-dev] Where to store intermediate data?
>>> >
>>> > The Titan implementation already provides caching. When you say a Map
>>> like API, you mean to access the data on the nodes?
>>> >
>>> > >From an intermediate data perspective, you can always get the
>>> underlying vertex from the Framed Vertex, and then write to it like a Map
>>> (Key, Value pair).
>>> >
>>> > Brad Davis
>>> > Red Hat Consulting
>>> > Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>>> >
>>> >
>>> > ----- Original Message -----
>>> > From: "Ondrej Zizka" <ozizka at redhat.com>
>>> > To: "Windup-dev List" <windup-dev at lists.jboss.org>
>>> > Sent: Friday, July 25, 2014 2:02:06 PM
>>> > Subject: [windup-dev] Where to store intermediate data?
>>> >
>>> > 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
>>> > _______________________________________________
>>> > windup-dev mailing list
>>> > windup-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/windup-dev
>>> > _______________________________________________
>>> > windup-dev mailing list
>>> > windup-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/windup-dev
>>> > _______________________________________________
>>> > windup-dev mailing list
>>> > windup-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/windup-dev
>>>
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>
>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.org
>> "Simpler is better."
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140725/84683b2b/attachment.html
From ozizka at redhat.com Fri Jul 25 15:46:20 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 25 Jul 2014 21:46:20 +0200
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <CAEp_U4H3ieCjvkYLjpSbzNxgwy9oM8QCs2k3ZRmN2-9=LQW0mw@mail.gmail.com>
References: <53D29B9E.9070305@redhat.com>
<CAEp_U4H3ieCjvkYLjpSbzNxgwy9oM8QCs2k3ZRmN2-9=LQW0mw@mail.gmail.com>
Message-ID: <53D2B40C.7070802@redhat.com>
Not a format. Other data.
On 25.7.2014 21:25, Lincoln Baxter, III wrote:
> Hey Ondra,
>
> The model Metadata is already available via the GraphTypeRegistry/etc.
> I would recommend that if there is some other view or format that you
> need for this data, then consider extending the existing API to
> support your use case - e.g. Return a map view, for example.
>
> ~Lincoln
>
>
> On Fri, Jul 25, 2014 at 2:02 PM, Ondrej Zizka <ozizka at redhat.com
> <mailto:ozizka at redhat.com>> wrote:
>
> 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
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140725/0a89cdec/attachment.html
From ozizka at redhat.com Fri Jul 25 15:46:55 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 25 Jul 2014 21:46:55 +0200
Subject: [windup-dev] Where to store intermediate data?
In-Reply-To: <CAEp_U4Hp_ZwWTG-CZ0d=T00ic7iZqJ+Y+gGq13WCBWpdxvF=Vw@mail.gmail.com>
References: <53D29B9E.9070305@redhat.com> <CAEp_U4H3ieCjvkYLjpSbzNxgwy9oM8QCs2k3ZRmN2-9=LQW0mw@mail.gmail.com>
<CAEp_U4Hp_ZwWTG-CZ0d=T00ic7iZqJ+Y+gGq13WCBWpdxvF=Vw@mail.gmail.com>
Message-ID: <53D2B42F.70903@redhat.com>
On 25.7.2014 21:26, Lincoln Baxter, III wrote:
> As I was trying to communicate yesterday, I'm not sure why you need
> another storage location for this when we already have the data stored
> in the GraphTypeManager :)
No we don't. As I told yesterday. It's other data.
> I *am* open to ideas on this, but I need to see a technical reason to
> duplicate the info.
>
>
> On Fri, Jul 25, 2014 at 3:25 PM, Lincoln Baxter, III
> <lincolnbaxter at gmail.com <mailto:lincolnbaxter at gmail.com>> wrote:
>
> Hey Ondra,
>
> The model Metadata is already available via the
> GraphTypeRegistry/etc. I would recommend that if there is some
> other view or format that you need for this data, then consider
> extending the existing API to support your use case - e.g. Return
> a map view, for example.
>
> ~Lincoln
>
>
> On Fri, Jul 25, 2014 at 2:02 PM, Ondrej Zizka <ozizka at redhat.com
> <mailto:ozizka at redhat.com>> wrote:
>
> 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
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140725/e1668724/attachment.html
From ozizka at redhat.com Thu Jul 31 13:59:44 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 31 Jul 2014 19:59:44 +0200
Subject: [windup-dev] .when( new True() )
Message-ID: <53DA8410.1020101@redhat.com>
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");
}
}
From ozizka at redhat.com Thu Jul 31 14:33:57 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 31 Jul 2014 20:33:57 +0200
Subject: [windup-dev] .when( new True() )
In-Reply-To: <53DA8410.1020101@redhat.com>
References: <53DA8410.1020101@redhat.com>
Message-ID: <53DA8C15.5080603@redhat.com>
Note for myself: RuleSubset.perform()
On 31.7.2014 19:59, Ondrej Zizka wrote:
> 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");
> }
> }
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Thu Jul 31 16:29:07 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 31 Jul 2014 22:29:07 +0200
Subject: [windup-dev] Negative queries?
Message-ID: <53DAA713.8010700@redhat.com>
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
From ozizka at redhat.com Thu Jul 31 16:32:04 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 31 Jul 2014 22:32:04 +0200
Subject: [windup-dev] .when( new True() )
In-Reply-To: <53DA8C15.5080603@redhat.com>
References: <53DA8410.1020101@redhat.com> <53DA8C15.5080603@redhat.com>
Message-ID: <53DAA7C4.9010007@redhat.com>
Found - it was the other rule which just put the same string to stdout.
On 31.7.2014 20:33, Ondrej Zizka wrote:
> Note for myself: RuleSubset.perform()
>
>
> On 31.7.2014 19:59, Ondrej Zizka wrote:
>> 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");
>> }
>> }
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Thu Jul 31 23:05:06 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 01 Aug 2014 05:05:06 +0200
Subject: [windup-dev] .when( new True() )
In-Reply-To: <53DAA7C4.9010007@redhat.com>
References: <53DA8410.1020101@redhat.com> <53DA8C15.5080603@redhat.com>
<53DAA7C4.9010007@redhat.com>
Message-ID: <53DB03E2.9010401@redhat.com>
But this still applies:
>>> 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?