From lincolnbaxter at gmail.com Mon Jun 2 09:13:59 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Mon, 2 Jun 2014 09:13:59 -0400
Subject: [windup-dev] One possibility for templating
Message-ID: <CAEp_U4EetgrSE1C2UGdxYcVQ5-bL=OcM5Cs3xHY4fZS11FG08w@mail.gmail.com>
We could try groovy templates. I haven't looked at them yet but just saw
this and remembered it exists...
Al Sargent (@alsargent) tweeted at 3:37 AM on Sun, Jun 01, 2014:
Using the innovative Groovy template engine in Spring Boot
http://t.co/pr4hYJwcMa
(https://twitter.com/alsargent/status/473005275168141312)
Get the official Twitter app at https://twitter.com/download
---
Lincoln Baxter's Droid
http://ocpsoft.org
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140602/415ca209/attachment.html
From ozizka at redhat.com Tue Jun 3 18:14:59 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 03 Jun 2014 18:14:59 -0400
Subject: [windup-dev] About to change the maven artifacts structure;
directories too.
Message-ID: <538E48E3.30301@redhat.com>
In case you have something to push,
I am About to change the maven artifacts structure; directories too.
For the target structure, see
https://docs.google.com/document/d/1qI9f6997d1i3xU7jeDJQbsGTDu-dhQ3imw8hycz_9Ww/edit#heading=h.mthnpbt0y8wd
(came up from the F2F meeting)
Ondra
From ozizka at redhat.com Tue Jun 3 21:04:23 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 03 Jun 2014 21:04:23 -0400
Subject: [windup-dev] Some cleanup
Message-ID: <538E7097.4010504@redhat.com>
Hi,
I've deleted ~/.m2/org/jboss/windup, and then the build is a bit tricky.
Doesn't build at once - forge complains about resolving the version of a
test dependency. I had to set a version. Then I need to build
graph-parent, which complains about windup-parent. After building these
extra, everything builds.
This happens with 46ba7f6d5f.
More importantly, I've hit https://issues.jboss.org/browse/WINDUP-75
Can't reproduce, so not sure whether it's on our side or Titan.
Ondra
From ozizka at redhat.com Wed Jun 4 00:03:50 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 04 Jun 2014 00:03:50 -0400
Subject: [windup-dev] groupId's changed - see branch Restructure
In-Reply-To: <538E7097.4010504@redhat.com>
References: <538E7097.4010504@redhat.com>
Message-ID: <538E9AA6.4040309@redhat.com>
Jira: https://issues.jboss.org/browse/WINDUP-76
Was following layout at:
https://docs.google.com/document/d/1qI9f6997d1i3xU7jeDJQbsGTDu-dhQ3imw8hycz_9Ww/edit#heading=h.mthnpbt0y8wd
Currently the change only touches the G:A. Not directories. That's step
2 for Wednesday.
In case someone started before I do:
In NetBeans, drag & drop and package rename leverages git's rename
tracking, so we won't loose history of the files.
Ondra
On 3.6.2014 21:04, Ondrej Zizka wrote:
> Hi,
>
> I've deleted ~/.m2/org/jboss/windup, and then the build is a bit tricky.
> Doesn't build at once - forge complains about resolving the version of a
> test dependency. I had to set a version. Then I need to build
> graph-parent, which complains about windup-parent. After building these
> extra, everything builds.
> This happens with 46ba7f6d5f.
>
> More importantly, I've hit https://issues.jboss.org/browse/WINDUP-75
> Can't reproduce, so not sure whether it's on our side or Titan.
>
> Ondra
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From lincolnbaxter at gmail.com Wed Jun 4 13:25:12 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 4 Jun 2014 13:25:12 -0400
Subject: [windup-dev] Refactoring maven GAV/and project layout
Message-ID: <CAEp_U4Ey7CFS99PfOYvor2sekoHX26jBiuLXbw1s-pmX_wnAoQ@mail.gmail.com>
Hey Ondra,
Jess and I have been talking over the package rename and he convinced me
that we can simplify it a bit.
Please review:
https://docs.google.com/document/d/1qI9f6997d1i3xU7jeDJQbsGTDu-dhQ3imw8hycz_9Ww/edit#
Thanks,
--
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/20140604/8d4c6327/attachment.html
From ozizka at redhat.com Wed Jun 4 22:58:48 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 04 Jun 2014 22:58:48 -0400
Subject: [windup-dev] Restructing done.
Message-ID: <538FDCE8.80109@redhat.com>
Hi,
check the MoveDirs branch.
I've done it in 3 steps - Maven GA, then Java packages, then dirs.
It's possible that I ommited something.
What's left: Split exec into /ext/config-xml and /rules.
But now I'm hitting an exception in unzip code. Still sure about
prefering JDK over 3rd party?
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 14.726
sec <<< FAILURE! - in
org.jboss.windup.tests.application.WindupArchitectureTest
testRunWindup(org.jboss.windup.tests.application.WindupArchitectureTest)
Time elapsed: 2.211 sec <<< ERROR!
org.javassist.tmp.java.lang.RuntimeException_$$_javassist_7b56a6e9-75b1-47f4-a167-cd6f40a091bd:
null
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:215)
at java.util.zip.ZipFile.<init>(ZipFile.java:145)
at java.util.zip.ZipFile.<init>(ZipFile.java:159)
at org.jboss.windup.util.ZipUtil.unzipToFolder(ZipUtil.java:33)
at
org.jboss.windup.config.operation.ruleelement.UnzipArchiveToTemporaryFolder.unzipToTempDirectory(UnzipArchiveToTemporaryFolder.java:95)
at
org.jboss.windup.config.operation.ruleelement.UnzipArchiveToTemporaryFolder.perform(UnzipArchiveToTemporaryFolder.java:61)
at
org.jboss.windup.config.operation.ruleelement.UnzipArchiveToTemporaryFolder.perform(UnzipArchiveToTemporaryFolder.java:23)
at
org.jboss.windup.config.operation.ruleelement.AbstractIterationOperator.perform(AbstractIterationOperator.java:31)
at
org.jboss.windup.config.operation.GraphOperation.perform(GraphOperation.java:24)
at
org.jboss.windup.config.operation.Iteration.perform(Iteration.java:149)
at
org.jboss.windup.config.operation.Iteration.perform(Iteration.java:134)
at
org.ocpsoft.rewrite.config.DefaultOperationBuilder$DefaultCompositeOperation.perform(DefaultOperationBuilder.java:56)
at
org.ocpsoft.rewrite.config.RuleBuilder.perform(RuleBuilder.java:136)
at
org.ocpsoft.rewrite.config.DefaultOperationBuilder$DefaultCompositeOperation.perform(DefaultOperationBuilder.java:56)
at
org.ocpsoft.rewrite.config.RuleBuilder.perform(RuleBuilder.java:136)
at
org.jboss.windup.config.GraphSubset.perform(GraphSubset.java:126)
at
org.jboss.windup.exec.ConfigurationProcessorImpl.run(ConfigurationProcessorImpl.java:41)
at
org.jboss.windup.exec.WindupProcessorImpl.execute(WindupProcessorImpl.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:59)
at
org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
at
org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:75)
at
org.jboss.windup.exec.WindupProcessorImpl_$$_javassist_62a491cc-be9f-4153-b8c5-c048e9b5384e.execute(WindupProcessorImpl_$$_javassist_62a491cc-be9f-4153-b8c5-c048e9b5384e.java)
at
org.jboss.windup.tests.application.WindupArchitectureTest.testRunWindup(WindupArchitectureTest.java:62)
Ondra
From ozizka at redhat.com Wed Jun 4 23:23:46 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 04 Jun 2014 23:23:46 -0400
Subject: [windup-dev] Restructing done.
In-Reply-To: <538FDCE8.80109@redhat.com>
References: <538FDCE8.80109@redhat.com>
Message-ID: <538FE2C2.6040104@redhat.com>
Interesting, I am not able to catch the exception in any way.
Must be some OCP javaassist stuff.
This project is going to be hard to debug.
Ondra
On 4.6.2014 22:58, Ondrej Zizka wrote:
> Hi,
>
> check the MoveDirs branch.
> I've done it in 3 steps - Maven GA, then Java packages, then dirs.
> It's possible that I ommited something.
>
> What's left: Split exec into /ext/config-xml and /rules.
>
> But now I'm hitting an exception in unzip code. Still sure about
> prefering JDK over 3rd party?
>
>
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 14.726
> sec <<< FAILURE! - in
> org.jboss.windup.tests.application.WindupArchitectureTest
> testRunWindup(org.jboss.windup.tests.application.WindupArchitectureTest)
> Time elapsed: 2.211 sec <<< ERROR!
> org.javassist.tmp.java.lang.RuntimeException_$$_javassist_7b56a6e9-75b1-47f4-a167-cd6f40a091bd:
> null
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:215)
> at java.util.zip.ZipFile.<init>(ZipFile.java:145)
> at java.util.zip.ZipFile.<init>(ZipFile.java:159)
> at org.jboss.windup.util.ZipUtil.unzipToFolder(ZipUtil.java:33)
> at
> org.jboss.windup.config.operation.ruleelement.UnzipArchiveToTemporaryFolder.unzipToTempDirectory(UnzipArchiveToTemporaryFolder.java:95)
> at
> org.jboss.windup.config.operation.ruleelement.UnzipArchiveToTemporaryFolder.perform(UnzipArchiveToTemporaryFolder.java:61)
> at
> org.jboss.windup.config.operation.ruleelement.UnzipArchiveToTemporaryFolder.perform(UnzipArchiveToTemporaryFolder.java:23)
> at
> org.jboss.windup.config.operation.ruleelement.AbstractIterationOperator.perform(AbstractIterationOperator.java:31)
> at
> org.jboss.windup.config.operation.GraphOperation.perform(GraphOperation.java:24)
> at
> org.jboss.windup.config.operation.Iteration.perform(Iteration.java:149)
> at
> org.jboss.windup.config.operation.Iteration.perform(Iteration.java:134)
> at
> org.ocpsoft.rewrite.config.DefaultOperationBuilder$DefaultCompositeOperation.perform(DefaultOperationBuilder.java:56)
> at
> org.ocpsoft.rewrite.config.RuleBuilder.perform(RuleBuilder.java:136)
> at
> org.ocpsoft.rewrite.config.DefaultOperationBuilder$DefaultCompositeOperation.perform(DefaultOperationBuilder.java:56)
> at
> org.ocpsoft.rewrite.config.RuleBuilder.perform(RuleBuilder.java:136)
> at
> org.jboss.windup.config.GraphSubset.perform(GraphSubset.java:126)
> at
> org.jboss.windup.exec.ConfigurationProcessorImpl.run(ConfigurationProcessorImpl.java:41)
> at
> org.jboss.windup.exec.WindupProcessorImpl.execute(WindupProcessorImpl.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:59)
> at
> org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
> at
> org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:75)
> at
> org.jboss.windup.exec.WindupProcessorImpl_$$_javassist_62a491cc-be9f-4153-b8c5-c048e9b5384e.execute(WindupProcessorImpl_$$_javassist_62a491cc-be9f-4153-b8c5-c048e9b5384e.java)
> at
> org.jboss.windup.tests.application.WindupArchitectureTest.testRunWindup(WindupArchitectureTest.java:62)
>
>
>
>
> Ondra
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From lincolnbaxter at gmail.com Thu Jun 5 10:31:26 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Thu, 5 Jun 2014 10:31:26 -0400
Subject: [windup-dev] Restructing done.
In-Reply-To: <538FE2C2.6040104@redhat.com>
References: <538FDCE8.80109@redhat.com>
<538FE2C2.6040104@redhat.com>
Message-ID: <CAEp_U4EeqdHzih4rmvEFiFcibjooP3Lh6MpJpU4fKh-x8HYtaA@mail.gmail.com>
OCP does nothing with Javassist ;) Furnace however does everything with it.
I'll take a look.
On Wed, Jun 4, 2014 at 11:23 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Interesting, I am not able to catch the exception in any way.
> Must be some OCP javaassist stuff.
> This project is going to be hard to debug.
>
> Ondra
>
>
>
> On 4.6.2014 22:58, Ondrej Zizka wrote:
> > Hi,
> >
> > check the MoveDirs branch.
> > I've done it in 3 steps - Maven GA, then Java packages, then dirs.
> > It's possible that I ommited something.
> >
> > What's left: Split exec into /ext/config-xml and /rules.
> >
> > But now I'm hitting an exception in unzip code. Still sure about
> > prefering JDK over 3rd party?
> >
> >
> > Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 14.726
> > sec <<< FAILURE! - in
> > org.jboss.windup.tests.application.WindupArchitectureTest
> > testRunWindup(org.jboss.windup.tests.application.WindupArchitectureTest)
> > Time elapsed: 2.211 sec <<< ERROR!
> >
> org.javassist.tmp.java.lang.RuntimeException_$$_javassist_7b56a6e9-75b1-47f4-a167-cd6f40a091bd:
> > null
> > at java.util.zip.ZipFile.open(Native Method)
> > at java.util.zip.ZipFile.<init>(ZipFile.java:215)
> > at java.util.zip.ZipFile.<init>(ZipFile.java:145)
> > at java.util.zip.ZipFile.<init>(ZipFile.java:159)
> > at org.jboss.windup.util.ZipUtil.unzipToFolder(ZipUtil.java:33)
> > at
> >
> org.jboss.windup.config.operation.ruleelement.UnzipArchiveToTemporaryFolder.unzipToTempDirectory(UnzipArchiveToTemporaryFolder.java:95)
> > at
> >
> org.jboss.windup.config.operation.ruleelement.UnzipArchiveToTemporaryFolder.perform(UnzipArchiveToTemporaryFolder.java:61)
> > at
> >
> org.jboss.windup.config.operation.ruleelement.UnzipArchiveToTemporaryFolder.perform(UnzipArchiveToTemporaryFolder.java:23)
> > at
> >
> org.jboss.windup.config.operation.ruleelement.AbstractIterationOperator.perform(AbstractIterationOperator.java:31)
> > at
> >
> org.jboss.windup.config.operation.GraphOperation.perform(GraphOperation.java:24)
> > at
> > org.jboss.windup.config.operation.Iteration.perform(Iteration.java:149)
> > at
> > org.jboss.windup.config.operation.Iteration.perform(Iteration.java:134)
> > at
> >
> org.ocpsoft.rewrite.config.DefaultOperationBuilder$DefaultCompositeOperation.perform(DefaultOperationBuilder.java:56)
> > at
> > org.ocpsoft.rewrite.config.RuleBuilder.perform(RuleBuilder.java:136)
> > at
> >
> org.ocpsoft.rewrite.config.DefaultOperationBuilder$DefaultCompositeOperation.perform(DefaultOperationBuilder.java:56)
> > at
> > org.ocpsoft.rewrite.config.RuleBuilder.perform(RuleBuilder.java:136)
> > at
> > org.jboss.windup.config.GraphSubset.perform(GraphSubset.java:126)
> > at
> >
> org.jboss.windup.exec.ConfigurationProcessorImpl.run(ConfigurationProcessorImpl.java:41)
> > at
> >
> org.jboss.windup.exec.WindupProcessorImpl.execute(WindupProcessorImpl.java:29)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:606)
> > at
> >
> org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:59)
> > at
> > org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
> > at
> >
> org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:75)
> > at
> >
> org.jboss.windup.exec.WindupProcessorImpl_$$_javassist_62a491cc-be9f-4153-b8c5-c048e9b5384e.execute(WindupProcessorImpl_$$_javassist_62a491cc-be9f-4153-b8c5-c048e9b5384e.java)
> > at
> >
> org.jboss.windup.tests.application.WindupArchitectureTest.testRunWindup(WindupArchitectureTest.java:62)
> >
> >
> >
> >
> > 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
>
--
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/20140605/6448bbd7/attachment-0001.html
From lincolnbaxter at gmail.com Thu Jun 5 12:42:34 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Thu, 05 Jun 2014 16:42:34 +0000
Subject: [windup-dev] Invitation: Windup Status Meeting @ Weekly from 12pm
to 1pm on Wednesday (Lincoln Baxter, III)
Message-ID: <e89a8f13ec8290e0dd04fb196eba@google.com>
You have been invited to the following event.
Title: Windup Status Meeting
When: Weekly from 12pm to 1pm on Wednesday Eastern Time
Where: #windup on irc.freenode.net
Calendar: Lincoln Baxter, III
Who:
* Lincoln Baxter, III - organizer
* ozizka at redhat.com
* Robb Greathouse
* windup-dev at lists.jboss.org
* Jesse Sightler
* pmuir at redhat.com
* Pete Muir
* Ondra ?i?ka
* jsightle at redhat.com
* Robb Greathouse
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=bGQzb2FiYmE3Z2s3dmlmYWYyZmZlNTBhdmcgd2luZHVwLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjMjbGluY29sbmJheHRlckBnbWFpbC5jb21iMDZhYTVkNjhmOTgxYzE1MTg2NjMwZmZlMmQ1M2E1MzBlNmQxMzk2&ctz=America/New_York&hl=en
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
windup-dev at lists.jboss.org because you are an attendee of this event.
To stop receiving future notifications for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/af2e6556/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2659 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/af2e6556/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2722 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/af2e6556/attachment-0001.bin
From lincolnbaxter at gmail.com Thu Jun 5 12:44:08 2014
From: lincolnbaxter at gmail.com (lincolnbaxter at gmail.com)
Date: Thu, 05 Jun 2014 16:44:08 +0000
Subject: [windup-dev] Updated Invitation: Windup Status Meeting @ Weekly
from 12pm to 1:01pm on Wednesday (Windup Project Calendar)
Message-ID: <e89a8f50316c29430a04fb19741a@google.com>
This event has been changed.
Title: Windup Status Meeting
When: Weekly from 12pm to 1:01pm on Wednesday Eastern Time (changed)
Where: #windup on irc.freenode.net
Calendar: Windup Project Calendar
Who:
* Lincoln Baxter, III - creator
* windup-dev at lists.jboss.org
* Pete Muir
* jsightle at redhat.com
* Ondra ?i?ka
* ozizka at redhat.com
* Robb Greathouse
* pmuir at redhat.com
* Robb Greathouse
* Jesse Sightler
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=bGQzb2FiYmE3Z2s3dmlmYWYyZmZlNTBhdmcgd2luZHVwLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=NTIjbThxYjFhZTZyYTJtZWZqNmc4Y2c3bHVlOTRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbTYwZDQxYTA2MDQyYTY2NjZlODQyMDI5MGQwNzVmN2I5MmJiNzFkNTM&ctz=America/New_York&hl=en
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
windup-dev at lists.jboss.org because you are an attendee of this event.
To stop receiving future notifications for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/8b861f04/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2911 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/8b861f04/attachment-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2979 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/8b861f04/attachment-0003.bin
From lincolnbaxter at gmail.com Thu Jun 5 12:47:00 2014
From: lincolnbaxter at gmail.com (lincolnbaxter at gmail.com)
Date: Thu, 05 Jun 2014 16:47:00 +0000
Subject: [windup-dev] Invitation: Windup Status Meeting @ Weekly from 12pm
to 1pm on Wednesday (Windup Project Calendar)
Message-ID: <089e0149be88663e7b04fb197e38@google.com>
You have been invited to the following event.
Title: Windup Status Meeting
When: Weekly from 12pm to 1pm on Wednesday Eastern Time
Where: #windup on irc.freenode.net
Calendar: Windup Project Calendar
Who:
* Lincoln Baxter, III - creator
* windup-dev at lists.jboss.org
* Ondra ?i?ka
* Robb Greathouse
* Jesse Sightler
* Brad Davis
* Pete Muir
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=bGQzb2FiYmE3Z2s3dmlmYWYyZmZlNTBhdmcgd2luZHVwLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=NTIjbThxYjFhZTZyYTJtZWZqNmc4Y2c3bHVlOTRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbTYwZDQxYTA2MDQyYTY2NjZlODQyMDI5MGQwNzVmN2I5MmJiNzFkNTM&ctz=America/New_York&hl=en
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
windup-dev at lists.jboss.org because you are an attendee of this event.
To stop receiving future notifications for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/6c230e14/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2320 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/6c230e14/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2380 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/6c230e14/attachment-0001.bin
From lincolnbaxter at gmail.com Thu Jun 5 12:59:30 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Thu, 5 Jun 2014 12:59:30 -0400
Subject: [windup-dev] Invitation: Windup Status Meeting @ Weekly from
12pm to 1pm on Wednesday (Windup Project Calendar)
In-Reply-To: <089e0149be88663e7b04fb197e38@google.com>
References: <089e0149be88663e7b04fb197e38@google.com>
Message-ID: <CAEp_U4GQadRLpqjKV4PubUh6EgwNPb=DLdaQ2OxNGsQj_r8OtQ@mail.gmail.com>
Sorry about the spam... this is the correct invite. Got it sorted out now.
On Thu, Jun 5, 2014 at 12:47 PM, lincolnbaxter at gmail.com <
lincolnbaxter at gmail.com> wrote:
> more details ?
> <https://www.google.com/calendar/event?action=VIEW&eid=bGQzb2FiYmE3Z2s3dmlmYWYyZmZlNTBhdmcgd2luZHVwLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=NTIjbThxYjFhZTZyYTJtZWZqNmc4Y2c3bHVlOTRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbTYwZDQxYTA2MDQyYTY2NjZlODQyMDI5MGQwNzVmN2I5MmJiNzFkNTM&ctz=America/New_York&hl=en>
> Windup Status Meeting
> *When*
> Weekly from 12pm to 1pm on Wednesday Eastern Time
> *Where*
> #windup on irc.freenode.net (map
> <http://maps.google.com/maps?q=%23windup+on+irc.freenode.net&hl=en>)
> *Calendar*
> Windup Project Calendar
> *Who*
> ?
> Lincoln Baxter, III - creator
> ?
> windup-dev at lists.jboss.org
> ?
> Ondra ?i?ka
> ?
> Robb Greathouse
> ?
> Jesse Sightler
> ?
> Brad Davis
> ?
> Pete Muir
>
> Going? All events in this series: *Yes
> <https://www.google.com/calendar/event?action=RESPOND&eid=bGQzb2FiYmE3Z2s3dmlmYWYyZmZlNTBhdmcgd2luZHVwLWRldkBsaXN0cy5qYm9zcy5vcmc&rst=1&tok=NTIjbThxYjFhZTZyYTJtZWZqNmc4Y2c3bHVlOTRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbTYwZDQxYTA2MDQyYTY2NjZlODQyMDI5MGQwNzVmN2I5MmJiNzFkNTM&ctz=America/New_York&hl=en>
> - Maybe
> <https://www.google.com/calendar/event?action=RESPOND&eid=bGQzb2FiYmE3Z2s3dmlmYWYyZmZlNTBhdmcgd2luZHVwLWRldkBsaXN0cy5qYm9zcy5vcmc&rst=3&tok=NTIjbThxYjFhZTZyYTJtZWZqNmc4Y2c3bHVlOTRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbTYwZDQxYTA2MDQyYTY2NjZlODQyMDI5MGQwNzVmN2I5MmJiNzFkNTM&ctz=America/New_York&hl=en>
> - No
> <https://www.google.com/calendar/event?action=RESPOND&eid=bGQzb2FiYmE3Z2s3dmlmYWYyZmZlNTBhdmcgd2luZHVwLWRldkBsaXN0cy5qYm9zcy5vcmc&rst=2&tok=NTIjbThxYjFhZTZyYTJtZWZqNmc4Y2c3bHVlOTRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbTYwZDQxYTA2MDQyYTY2NjZlODQyMDI5MGQwNzVmN2I5MmJiNzFkNTM&ctz=America/New_York&hl=en>*
> more options ?
> <https://www.google.com/calendar/event?action=VIEW&eid=bGQzb2FiYmE3Z2s3dmlmYWYyZmZlNTBhdmcgd2luZHVwLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=NTIjbThxYjFhZTZyYTJtZWZqNmc4Y2c3bHVlOTRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbTYwZDQxYTA2MDQyYTY2NjZlODQyMDI5MGQwNzVmN2I5MmJiNzFkNTM&ctz=America/New_York&hl=en>
>
> Invitation from Google Calendar <https://www.google.com/calendar/>
>
> You are receiving this courtesy email at the account
> windup-dev at lists.jboss.org because you are an attendee of this event.
>
> To stop receiving future notifications for this event, decline this event.
> Alternatively you can sign up for a Google account at
> https://www.google.com/calendar/ and control your notification settings
> for your entire calendar.
>
> _______________________________________________
> 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/20140605/a88d1a09/attachment-0001.html
From lincolnbaxter at gmail.com Thu Jun 5 16:50:43 2014
From: lincolnbaxter at gmail.com (lincolnbaxter at gmail.com)
Date: Thu, 05 Jun 2014 20:50:43 +0000
Subject: [windup-dev] Updated Invitation: Windup Status Meeting @ Weekly
from 10am to 11am on Wednesday (Windup Project Calendar)
Message-ID: <047d7b6d89ee00172004fb1ce694@google.com>
This event has been changed.
Title: Windup Status Meeting
When: Weekly from 10am to 11am on Wednesday Eastern Time (changed)
Where: #windup on irc.freenode.net
Calendar: Windup Project Calendar
Who:
* Lincoln Baxter, III - creator
* windup-dev at lists.jboss.org
* Ondra ?i?ka
* Robb Greathouse
* Jesse Sightler
* Brad Davis
* Pete Muir
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=bGQzb2FiYmE3Z2s3dmlmYWYyZmZlNTBhdmcgd2luZHVwLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=NTIjbThxYjFhZTZyYTJtZWZqNmc4Y2c3bHVlOTRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbTYwZDQxYTA2MDQyYTY2NjZlODQyMDI5MGQwNzVmN2I5MmJiNzFkNTM&ctz=America/New_York&hl=en
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
windup-dev at lists.jboss.org because you are an attendee of this event.
To stop receiving future notifications for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/97dd682f/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2320 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/97dd682f/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2380 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140605/97dd682f/attachment-0001.bin
From robb.greathouse at redhat.com Fri Jun 6 14:24:56 2014
From: robb.greathouse at redhat.com (Robb Greathouse)
Date: Fri, 6 Jun 2014 14:24:56 -0400 (EDT)
Subject: [windup-dev] Articles for Windup
In-Reply-To: <1409245575.18160792.1402077298819.JavaMail.zimbra@redhat.com>
Message-ID: <2047319300.18173828.1402079096338.JavaMail.zimbra@redhat.com>
Hi,
We want to prepare articles to go out to industry websites and on-line mags to coincide with the September/October release of Windup.
Here are some titles we have kicked around:
"Migrating to JBoss Just Got Much Easier"
"Prospects for Automating Migrations"
"Windup: What's New"
"Importance of Classification in Estimating Costs of Migration"
"How To Write a Plugin For Windup" or "How To Add Your Favorite Tool To Windup"
"Writing Your Own Migration Rules"
If anyone has other ideas or thoughts they can contribute to these, we would love to hear from you.
Robb Greathouse
Chief Evangelist
Middleware Business Unit
JBoss, a Division of Red Hat
cellphone 505-507-4906
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140606/6ddc19f1/attachment.html
From itewksbu at redhat.com Mon Jun 9 08:27:11 2014
From: itewksbu at redhat.com (Ian Tewksbury)
Date: Mon, 9 Jun 2014 08:27:11 -0400 (EDT)
Subject: [windup-dev] Articles for Windup
In-Reply-To: <2047319300.18173828.1402079096338.JavaMail.zimbra@redhat.com>
References: <2047319300.18173828.1402079096338.JavaMail.zimbra@redhat.com>
Message-ID: <1556889490.16271743.1402316831027.JavaMail.zimbra@redhat.com>
Robb,
My one suggested would be something along the lines of:
"Integrating Windup with Your Existing Eclipse Development Environment"
AKA, some plug for the Eclipse plugin.
Blue Skies,
~Ian
----- Original Message -----
From: "Robb Greathouse" <robb.greathouse at redhat.com>
To: "windup-dev" <windup-dev at lists.jboss.org>
Sent: Friday, June 6, 2014 2:24:56 PM
Subject: [windup-dev] Articles for Windup
Hi,
We want to prepare articles to go out to industry websites and on-line mags to coincide with the September/October release of Windup.
Here are some titles we have kicked around:
"Migrating to JBoss Just Got Much Easier"
"Prospects for Automating Migrations"
"Windup: What's New"
"Importance of Classification in Estimating Costs of Migration"
"How To Write a Plugin For Windup" or "How To Add Your Favorite Tool To Windup"
"Writing Your Own Migration Rules"
If anyone has other ideas or thoughts they can contribute to these, we would love to hear from you.
Robb Greathouse
Chief Evangelist
Middleware Business Unit
JBoss, a Division of Red Hat
cellphone 505-507-4906
_______________________________________________
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/20140609/20b634ea/attachment-0001.html
From itewksbu at redhat.com Mon Jun 9 23:08:27 2014
From: itewksbu at redhat.com (Ian Tewksbury)
Date: Mon, 9 Jun 2014 23:08:27 -0400 (EDT)
Subject: [windup-dev] org.springframework.context.ApplicationContext
In-Reply-To: <2138170229.16678031.1402369528632.JavaMail.zimbra@redhat.com>
Message-ID: <479981310.16678165.1402369707452.JavaMail.zimbra@redhat.com>
Windup Team,
I am trying to get the Windup Eclipse plugin to work with Windup 2.0 using Forge. The latest issue I am running into is that Eclipse can not find org.springframework.context.ApplicationContext. For that matter I can not find it either. I searched my workspace that has windup, windup-eclipse-plugin, and jboss-forge, and none of the included plugins or library jars seem to have this class. By which magic does Windup normally load this class? I need to figure out how Windup loads the class so I can load it via the plugin as well.
java.lang.NoClassDefFoundError: org/springframework/context/ApplicationContext
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2493)
at java.lang.Class.getConstructor0(Class.java:2803)
at java.lang.Class.getConstructor(Class.java:1718)
at org.jboss.forge.furnace.proxy.Proxies.isInstantiable(Proxies.java:414)
at org.jboss.forge.furnace.proxy.ProxyTypeInspector.getCompatibleClassHierarchy(ProxyTypeInspector.java:40)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.enhanceResult(ClassLoaderAdapterCallback.java:240)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.access$300(ClassLoaderAdapterCallback.java:34)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback$2.call(ClassLoaderAdapterCallback.java:117)
at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.invoke(ClassLoaderAdapterCallback.java:89)
at org.jboss.windup.WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.createWindupEngine(WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.java)
at org.jboss.tools.windup.core.WindupService.getWindupEngine(WindupService.java:391)
at org.jboss.tools.windup.core.WindupService.getWindupReportEngine(WindupService.java:412)
at org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:250)
at org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:186)
at org.jboss.tools.windup.ui.internal.commands.GenerateWindupReportHandler$1.run(GenerateWindupReportHandler.java:78)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.ClassNotFoundException: org.springframework.context.ApplicationContext cannot be found by org.jboss.tools.windup.runtime_3.1.0.qualifier
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:336)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:328)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 18 more
Blue Skies,
~Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140609/3da371e2/attachment.html
From lincolnbaxter at gmail.com Tue Jun 10 01:17:29 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Tue, 10 Jun 2014 01:17:29 -0400
Subject: [windup-dev] org.springframework.context.ApplicationContext
In-Reply-To: <479981310.16678165.1402369707452.JavaMail.zimbra@redhat.com>
References: <2138170229.16678031.1402369528632.JavaMail.zimbra@redhat.com>
<479981310.16678165.1402369707452.JavaMail.zimbra@redhat.com>
Message-ID: <CAEp_U4HwRrTpTEpWR+JbExzxZ9SST7J7974HnmVDY2ELb1CpPQ@mail.gmail.com>
This is something that is probably no longer in the windup/windup/master
branch, which could certainly lead to being missing. It has probabaly moved
to the windup/windup-legacy repository (we split it out a week ago.)
On Mon, Jun 9, 2014 at 11:08 PM, Ian Tewksbury <itewksbu at redhat.com> wrote:
> Windup Team,
>
>
> I am trying to get the Windup Eclipse plugin to work with Windup 2.0 using
> Forge. The latest issue I am running into is that Eclipse can not find
> org.springframework.context.ApplicationContext. For that matter I can not
> find it either. I searched my workspace that has windup,
> windup-eclipse-plugin, and jboss-forge, and none of the included plugins or
> library jars seem to have this class. By which magic does Windup normally
> load this class? I need to figure out how Windup loads the class so I can
> load it via the plugin as well.
>
>
> java.lang.NoClassDefFoundError:
> org/springframework/context/ApplicationContext
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2493)
> at java.lang.Class.getConstructor0(Class.java:2803)
> at java.lang.Class.getConstructor(Class.java:1718)
> at org.jboss.forge.furnace.proxy.Proxies.isInstantiable(Proxies.java:414)
> at
> org.jboss.forge.furnace.proxy.ProxyTypeInspector.getCompatibleClassHierarchy(ProxyTypeInspector.java:40)
> at
> org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.enhanceResult(ClassLoaderAdapterCallback.java:240)
> at
> org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.access$300(ClassLoaderAdapterCallback.java:34)
> at
> org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback$2.call(ClassLoaderAdapterCallback.java:117)
> at
> org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
> at
> org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.invoke(ClassLoaderAdapterCallback.java:89)
> at
> org.jboss.windup.WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.createWindupEngine(WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.java)
> at
> org.jboss.tools.windup.core.WindupService.getWindupEngine(WindupService.java:391)
> at
> org.jboss.tools.windup.core.WindupService.getWindupReportEngine(WindupService.java:412)
> at
> org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:250)
> at
> org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:186)
> at
> org.jboss.tools.windup.ui.internal.commands.GenerateWindupReportHandler$1.run(GenerateWindupReportHandler.java:78)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> Caused by: java.lang.ClassNotFoundException:
> org.springframework.context.ApplicationContext cannot be found by
> org.jboss.tools.windup.runtime_3.1.0.qualifier
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:336)
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:328)
> at
> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> ... 18 more
>
> 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/20140610/3f6fe4bf/attachment.html
From itewksbu at redhat.com Tue Jun 10 08:39:44 2014
From: itewksbu at redhat.com (Ian Tewksbury)
Date: Tue, 10 Jun 2014 08:39:44 -0400 (EDT)
Subject: [windup-dev] org.springframework.context.ApplicationContext
In-Reply-To: <CAEp_U4HwRrTpTEpWR+JbExzxZ9SST7J7974HnmVDY2ELb1CpPQ@mail.gmail.com>
References: <2138170229.16678031.1402369528632.JavaMail.zimbra@redhat.com>
<479981310.16678165.1402369707452.JavaMail.zimbra@redhat.com>
<CAEp_U4HwRrTpTEpWR+JbExzxZ9SST7J7974HnmVDY2ELb1CpPQ@mail.gmail.com>
Message-ID: <2145988928.16934143.1402403984122.JavaMail.zimbra@redhat.com>
is there any name overlapping between the windup-legacy and windup repos. As in, can both projects live in the same Eclipse workspace or do they require separate workspaces because there is name shadowing?
Is https://github.com/windup/windup-legacy/blob/master/application/addon/pom.xml now the artifact that i need to add as a furnace addon repo rather then org.jboss.windup.legacy.application:legacy-windup?
Blue Skies,
~Ian
----- Original Message -----
From: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
To: "Windup-dev List" <windup-dev at lists.jboss.org>
Sent: Tuesday, June 10, 2014 1:17:29 AM
Subject: Re: [windup-dev] org.springframework.context.ApplicationContext
This is something that is probably no longer in the windup/windup/master branch, which could certainly lead to being missing. It has probabaly moved to the windup/windup-legacy repository (we split it out a week ago.)
On Mon, Jun 9, 2014 at 11:08 PM, Ian Tewksbury < itewksbu at redhat.com > wrote:
Windup Team,
I am trying to get the Windup Eclipse plugin to work with Windup 2.0 using Forge. The latest issue I am running into is that Eclipse can not find org.springframework.context.ApplicationContext. For that matter I can not find it either. I searched my workspace that has windup, windup-eclipse-plugin, and jboss-forge, and none of the included plugins or library jars seem to have this class. By which magic does Windup normally load this class? I need to figure out how Windup loads the class so I can load it via the plugin as well.
java.lang.NoClassDefFoundError: org/springframework/context/ApplicationContext
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2493)
at java.lang.Class.getConstructor0(Class.java:2803)
at java.lang.Class.getConstructor(Class.java:1718)
at org.jboss.forge.furnace.proxy.Proxies.isInstantiable(Proxies.java:414)
at org.jboss.forge.furnace.proxy.ProxyTypeInspector.getCompatibleClassHierarchy(ProxyTypeInspector.java:40)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.enhanceResult(ClassLoaderAdapterCallback.java:240)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.access$300(ClassLoaderAdapterCallback.java:34)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback$2.call(ClassLoaderAdapterCallback.java:117)
at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.invoke(ClassLoaderAdapterCallback.java:89)
at org.jboss.windup.WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.createWindupEngine(WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.java)
at org.jboss.tools.windup.core.WindupService.getWindupEngine(WindupService.java:391)
at org.jboss.tools.windup.core.WindupService.getWindupReportEngine(WindupService.java:412)
at org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:250)
at org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:186)
at org.jboss.tools.windup.ui.internal.commands.GenerateWindupReportHandler$1.run(GenerateWindupReportHandler.java:78)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.ClassNotFoundException: org.springframework.context.ApplicationContext cannot be found by org.jboss.tools.windup.runtime_3.1.0.qualifier
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:336)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:328)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 18 more
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."
_______________________________________________
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/20140610/a853ecb7/attachment-0001.html
From lincolnbaxter at gmail.com Tue Jun 10 11:49:58 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Tue, 10 Jun 2014 11:49:58 -0400
Subject: [windup-dev] org.springframework.context.ApplicationContext
In-Reply-To: <2145988928.16934143.1402403984122.JavaMail.zimbra@redhat.com>
References: <2138170229.16678031.1402369528632.JavaMail.zimbra@redhat.com>
<479981310.16678165.1402369707452.JavaMail.zimbra@redhat.com>
<CAEp_U4HwRrTpTEpWR+JbExzxZ9SST7J7974HnmVDY2ELb1CpPQ@mail.gmail.com>
<2145988928.16934143.1402403984122.JavaMail.zimbra@redhat.com>
Message-ID: <CAEp_U4FYN9zw20P_kQGN6gU9WjUaJsYp-FVFpggNo=2QFUYk0g@mail.gmail.com>
Yeah, looks like that's the one. Sorry about that. There should have been
an email that went out about this refactor.
On Tue, Jun 10, 2014 at 8:39 AM, Ian Tewksbury <itewksbu at redhat.com> wrote:
> is there any name overlapping between the windup-legacy and windup repos.
> As in, can both projects live in the same Eclipse workspace or do they
> require separate workspaces because there is name shadowing?
>
> Is
> https://github.com/windup/windup-legacy/blob/master/application/addon/pom.xml now
> the artifact that i need to add as a furnace addon repo rather
> then org.jboss.windup.legacy.application:legacy-windup?
>
> Blue Skies,
> ~Ian
>
> ------------------------------
> *From: *"Lincoln Baxter, III" <lincolnbaxter at gmail.com>
> *To: *"Windup-dev List" <windup-dev at lists.jboss.org>
> *Sent: *Tuesday, June 10, 2014 1:17:29 AM
> *Subject: *Re: [windup-dev] org.springframework.context.ApplicationContext
>
>
> This is something that is probably no longer in the windup/windup/master
> branch, which could certainly lead to being missing. It has probabaly moved
> to the windup/windup-legacy repository (we split it out a week ago.)
>
>
> On Mon, Jun 9, 2014 at 11:08 PM, Ian Tewksbury <itewksbu at redhat.com>
> wrote:
>
>> Windup Team,
>>
>>
>> I am trying to get the Windup Eclipse plugin to work with Windup 2.0
>> using Forge. The latest issue I am running into is that Eclipse can not
>> find org.springframework.context.ApplicationContext. For that matter I can
>> not find it either. I searched my workspace that has windup,
>> windup-eclipse-plugin, and jboss-forge, and none of the included plugins or
>> library jars seem to have this class. By which magic does Windup normally
>> load this class? I need to figure out how Windup loads the class so I can
>> load it via the plugin as well.
>>
>>
>> java.lang.NoClassDefFoundError:
>> org/springframework/context/ApplicationContext
>> at java.lang.Class.getDeclaredConstructors0(Native Method)
>> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2493)
>> at java.lang.Class.getConstructor0(Class.java:2803)
>> at java.lang.Class.getConstructor(Class.java:1718)
>> at org.jboss.forge.furnace.proxy.Proxies.isInstantiable(Proxies.java:414)
>> at
>> org.jboss.forge.furnace.proxy.ProxyTypeInspector.getCompatibleClassHierarchy(ProxyTypeInspector.java:40)
>> at
>> org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.enhanceResult(ClassLoaderAdapterCallback.java:240)
>> at
>> org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.access$300(ClassLoaderAdapterCallback.java:34)
>> at
>> org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback$2.call(ClassLoaderAdapterCallback.java:117)
>> at
>> org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
>> at
>> org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.invoke(ClassLoaderAdapterCallback.java:89)
>> at
>> org.jboss.windup.WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.createWindupEngine(WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.java)
>> at
>> org.jboss.tools.windup.core.WindupService.getWindupEngine(WindupService.java:391)
>> at
>> org.jboss.tools.windup.core.WindupService.getWindupReportEngine(WindupService.java:412)
>> at
>> org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:250)
>> at
>> org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:186)
>> at
>> org.jboss.tools.windup.ui.internal.commands.GenerateWindupReportHandler$1.run(GenerateWindupReportHandler.java:78)
>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
>> Caused by: java.lang.ClassNotFoundException:
>> org.springframework.context.ApplicationContext cannot be found by
>> org.jboss.tools.windup.runtime_3.1.0.qualifier
>> at
>> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
>> at
>> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:336)
>> at
>> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:328)
>> at
>> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>> ... 18 more
>>
>> 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."
>
> _______________________________________________
> 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/20140610/6795c131/attachment.html
From itewksbu at redhat.com Tue Jun 10 11:53:22 2014
From: itewksbu at redhat.com (Ian Tewksbury)
Date: Tue, 10 Jun 2014 11:53:22 -0400 (EDT)
Subject: [windup-dev] org.springframework.context.ApplicationContext
In-Reply-To: <CAEp_U4FYN9zw20P_kQGN6gU9WjUaJsYp-FVFpggNo=2QFUYk0g@mail.gmail.com>
References: <2138170229.16678031.1402369528632.JavaMail.zimbra@redhat.com>
<479981310.16678165.1402369707452.JavaMail.zimbra@redhat.com>
<CAEp_U4HwRrTpTEpWR+JbExzxZ9SST7J7974HnmVDY2ELb1CpPQ@mail.gmail.com>
<2145988928.16934143.1402403984122.JavaMail.zimbra@redhat.com>
<CAEp_U4FYN9zw20P_kQGN6gU9WjUaJsYp-FVFpggNo=2QFUYk0g@mail.gmail.com>
Message-ID: <1956940260.17073911.1402415602439.JavaMail.zimbra@redhat.com>
I saw some notifications about the refactor just didn't realize that the legacy stuff got moved out.
Thanks for the info. Attempt 2 tonight to get everything working.
Blue Skies,
~Ian
----- Original Message -----
From: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
To: "Windup-dev List" <windup-dev at lists.jboss.org>
Sent: Tuesday, June 10, 2014 11:49:58 AM
Subject: Re: [windup-dev] org.springframework.context.ApplicationContext
Yeah, looks like that's the one. Sorry about that. There should have been an email that went out about this refactor.
On Tue, Jun 10, 2014 at 8:39 AM, Ian Tewksbury < itewksbu at redhat.com > wrote:
is there any name overlapping between the windup-legacy and windup repos. As in, can both projects live in the same Eclipse workspace or do they require separate workspaces because there is name shadowing?
Is https://github.com/windup/windup-legacy/blob/master/application/addon/pom.xml now the artifact that i need to add as a furnace addon repo rather then org.jboss.windup.legacy.application:legacy-windup?
Blue Skies,
~Ian
From: "Lincoln Baxter, III" < lincolnbaxter at gmail.com >
To: "Windup-dev List" < windup-dev at lists.jboss.org >
Sent: Tuesday, June 10, 2014 1:17:29 AM
Subject: Re: [windup-dev] org.springframework.context.ApplicationContext
This is something that is probably no longer in the windup/windup/master branch, which could certainly lead to being missing. It has probabaly moved to the windup/windup-legacy repository (we split it out a week ago.)
On Mon, Jun 9, 2014 at 11:08 PM, Ian Tewksbury < itewksbu at redhat.com > wrote:
<blockquote>
Windup Team,
I am trying to get the Windup Eclipse plugin to work with Windup 2.0 using Forge. The latest issue I am running into is that Eclipse can not find org.springframework.context.ApplicationContext. For that matter I can not find it either. I searched my workspace that has windup, windup-eclipse-plugin, and jboss-forge, and none of the included plugins or library jars seem to have this class. By which magic does Windup normally load this class? I need to figure out how Windup loads the class so I can load it via the plugin as well.
java.lang.NoClassDefFoundError: org/springframework/context/ApplicationContext
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2493)
at java.lang.Class.getConstructor0(Class.java:2803)
at java.lang.Class.getConstructor(Class.java:1718)
at org.jboss.forge.furnace.proxy.Proxies.isInstantiable(Proxies.java:414)
at org.jboss.forge.furnace.proxy.ProxyTypeInspector.getCompatibleClassHierarchy(ProxyTypeInspector.java:40)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.enhanceResult(ClassLoaderAdapterCallback.java:240)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.access$300(ClassLoaderAdapterCallback.java:34)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback$2.call(ClassLoaderAdapterCallback.java:117)
at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.invoke(ClassLoaderAdapterCallback.java:89)
at org.jboss.windup.WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.createWindupEngine(WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.java)
at org.jboss.tools.windup.core.WindupService.getWindupEngine(WindupService.java:391)
at org.jboss.tools.windup.core.WindupService.getWindupReportEngine(WindupService.java:412)
at org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:250)
at org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:186)
at org.jboss.tools.windup.ui.internal.commands.GenerateWindupReportHandler$1.run(GenerateWindupReportHandler.java:78)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.ClassNotFoundException: org.springframework.context.ApplicationContext cannot be found by org.jboss.tools.windup.runtime_3.1.0.qualifier
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:336)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:328)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 18 more
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."
_______________________________________________
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
</blockquote>
--
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/20140610/92fbe72d/attachment.html
From lincolnbaxter at gmail.com Tue Jun 10 15:19:13 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Tue, 10 Jun 2014 15:19:13 -0400
Subject: [windup-dev] Test projects in windup/windup repository
Message-ID: <CAEp_U4HpCZ7spjb2+_U2_oZCbJHt-YFdDzsq5uyUmiJuywO8HQ@mail.gmail.com>
Hey All,
I think that we should move our sample-apps out of the windup repository
and into a separate one. These files confuse the build and clutter the
workspace (I usually end up deleting them.)
I recommend moving them into a separate repository. At the time when we
actually start using them, we can re-think where they should go if
necessary.
Currently we have:
https://github.com/windup/windup/tree/master/sample-apps
One possible home is: https://github.com/windup/windup-java-ee-tests - the
advantage of this is that it will be consistent with where other samples
are being maintained as they come in from contributors working on real
projects.
Thoughts?
--
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/20140610/9abd7df1/attachment-0001.html
From jsightle at redhat.com Tue Jun 10 21:32:38 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Tue, 10 Jun 2014 21:32:38 -0400 (EDT)
Subject: [windup-dev] Test projects in windup/windup repository
In-Reply-To: <CAEp_U4HpCZ7spjb2+_U2_oZCbJHt-YFdDzsq5uyUmiJuywO8HQ@mail.gmail.com>
References: <CAEp_U4HpCZ7spjb2+_U2_oZCbJHt-YFdDzsq5uyUmiJuywO8HQ@mail.gmail.com>
Message-ID: <873649182.18779108.1402450358219.JavaMail.zimbra@zmail09.collab.prod.int.phx2.redhat.com>
+1
On Jun 10, 2014 3:19 PM, "Lincoln Baxter, III" <lincolnbaxter at gmail.com> wrote:
Hey All,
I think that we should move our sample-apps out of the windup repository
and into a separate one. These files confuse the build and clutter the
workspace (I usually end up deleting them.)
I recommend moving them into a separate repository. At the time when we
actually start using them, we can re-think where they should go if
necessary.
Currently we have:
https://github.com/windup/windup/tree/master/sample-apps
One possible home is: https://github.com/windup/windup-java-ee-tests - the
advantage of this is that it will be consistent with where other samples
are being maintained as they come in from contributors working on real
projects.
Thoughts?
--
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/20140610/98ceab5b/attachment.html
-------------- next part --------------
_______________________________________________
windup-dev mailing list
windup-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
From itewksbu at redhat.com Tue Jun 10 22:21:31 2014
From: itewksbu at redhat.com (Ian Tewksbury)
Date: Tue, 10 Jun 2014 22:21:31 -0400 (EDT)
Subject: [windup-dev] org.springframework.context.ApplicationContext
In-Reply-To: <1956940260.17073911.1402415602439.JavaMail.zimbra@redhat.com>
References: <2138170229.16678031.1402369528632.JavaMail.zimbra@redhat.com>
<479981310.16678165.1402369707452.JavaMail.zimbra@redhat.com>
<CAEp_U4HwRrTpTEpWR+JbExzxZ9SST7J7974HnmVDY2ELb1CpPQ@mail.gmail.com>
<2145988928.16934143.1402403984122.JavaMail.zimbra@redhat.com>
<CAEp_U4FYN9zw20P_kQGN6gU9WjUaJsYp-FVFpggNo=2QFUYk0g@mail.gmail.com>
<1956940260.17073911.1402415602439.JavaMail.zimbra@redhat.com>
Message-ID: <549089224.17234151.1402453291210.JavaMail.zimbra@redhat.com>
I updated to use the windup-legacy project and forge addon but I am still seeing the same error that it can not find org.springframework.context.ApplicationContext.
The difference this time is that /org.jboss.tools.windup.runtime/furnace-addon-repository/org-jboss-windup-legacy-app-windup-legacy-app-addon-1-0-0-SNAPSHOT/spring-context-3.1.0.RELEASE.jar exists. So I would think that since Forge is reporting that the /org.jboss.tools.windup.runtime/furnace-addon-repository/org-jboss-windup-legacy-app-windup-legacy-app-addon-1-0-0-SNAPSHOT Forge addon is being succesfully loaded I should not see this issue any longer.
Lincoln, could you pull down the latest windup-eclupse-plugin forge branch code and the latest jbosstools-forge code (with my push that needs to be accepted) and see if you can figure out why Forge is not finding the class that is clearly in a jar in the loaded addon?
At this point I do not think this is an issue on the windup or windup-eclipse-plugin side but something on the Forge/Furnace side.
Blue Skies,
~Ian
----- Original Message -----
From: "Ian Tewksbury" <itewksbu at redhat.com>
To: "Windup-dev List" <windup-dev at lists.jboss.org>
Sent: Tuesday, June 10, 2014 11:53:22 AM
Subject: Re: [windup-dev] org.springframework.context.ApplicationContext
I saw some notifications about the refactor just didn't realize that the legacy stuff got moved out.
Thanks for the info. Attempt 2 tonight to get everything working.
Blue Skies,
~Ian
----- Original Message -----
From: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
To: "Windup-dev List" <windup-dev at lists.jboss.org>
Sent: Tuesday, June 10, 2014 11:49:58 AM
Subject: Re: [windup-dev] org.springframework.context.ApplicationContext
Yeah, looks like that's the one. Sorry about that. There should have been an email that went out about this refactor.
On Tue, Jun 10, 2014 at 8:39 AM, Ian Tewksbury < itewksbu at redhat.com > wrote:
is there any name overlapping between the windup-legacy and windup repos. As in, can both projects live in the same Eclipse workspace or do they require separate workspaces because there is name shadowing?
Is https://github.com/windup/windup-legacy/blob/master/application/addon/pom.xml now the artifact that i need to add as a furnace addon repo rather then org.jboss.windup.legacy.application:legacy-windup?
Blue Skies,
~Ian
From: "Lincoln Baxter, III" < lincolnbaxter at gmail.com >
To: "Windup-dev List" < windup-dev at lists.jboss.org >
Sent: Tuesday, June 10, 2014 1:17:29 AM
Subject: Re: [windup-dev] org.springframework.context.ApplicationContext
This is something that is probably no longer in the windup/windup/master branch, which could certainly lead to being missing. It has probabaly moved to the windup/windup-legacy repository (we split it out a week ago.)
On Mon, Jun 9, 2014 at 11:08 PM, Ian Tewksbury < itewksbu at redhat.com > wrote:
<blockquote>
Windup Team,
I am trying to get the Windup Eclipse plugin to work with Windup 2.0 using Forge. The latest issue I am running into is that Eclipse can not find org.springframework.context.ApplicationContext. For that matter I can not find it either. I searched my workspace that has windup, windup-eclipse-plugin, and jboss-forge, and none of the included plugins or library jars seem to have this class. By which magic does Windup normally load this class? I need to figure out how Windup loads the class so I can load it via the plugin as well.
java.lang.NoClassDefFoundError: org/springframework/context/ApplicationContext
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2493)
at java.lang.Class.getConstructor0(Class.java:2803)
at java.lang.Class.getConstructor(Class.java:1718)
at org.jboss.forge.furnace.proxy.Proxies.isInstantiable(Proxies.java:414)
at org.jboss.forge.furnace.proxy.ProxyTypeInspector.getCompatibleClassHierarchy(ProxyTypeInspector.java:40)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.enhanceResult(ClassLoaderAdapterCallback.java:240)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.access$300(ClassLoaderAdapterCallback.java:34)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback$2.call(ClassLoaderAdapterCallback.java:117)
at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.invoke(ClassLoaderAdapterCallback.java:89)
at org.jboss.windup.WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.createWindupEngine(WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.java)
at org.jboss.tools.windup.core.WindupService.getWindupEngine(WindupService.java:391)
at org.jboss.tools.windup.core.WindupService.getWindupReportEngine(WindupService.java:412)
at org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:250)
at org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:186)
at org.jboss.tools.windup.ui.internal.commands.GenerateWindupReportHandler$1.run(GenerateWindupReportHandler.java:78)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.ClassNotFoundException: org.springframework.context.ApplicationContext cannot be found by org.jboss.tools.windup.runtime_3.1.0.qualifier
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:336)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:328)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 18 more
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."
_______________________________________________
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
</blockquote>
--
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/20140610/3c2e5925/attachment.html
From lincolnbaxter at gmail.com Wed Jun 11 11:17:01 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 11 Jun 2014 11:17:01 -0400
Subject: [windup-dev] Windup Meeting minutes 2014-06-11
Message-ID: <CAEp_U4G+XoW=pFCmqkq8XWJtEY4smEhO9+X82Bt6LHxC2833PA@mail.gmail.com>
===============
#windup Meeting
===============
Meeting started by lincolnthree at 13:56:14 UTC.
Meeting summary
---------------
* Agenda (lincolnthree, 13:56:31)
* Groovy Rules (lincolnthree, 13:59:24)
* no technical barriers have become apparent (lincolnthree, 13:59:59)
* Eclipse Plugin (lincolnthree, 14:09:19)
* Exposing Furnace Runtime to Windup Eclipse addon is probably the way
to go. Will keep thinking and revisit if necessary (lincolnthree,
14:22:41)
* POMs and Logging (lincolnthree, 14:22:45)
* Lincoln is debugging through some POM/structure build issues while
working through the logging fixes (lincolnthree, 14:29:56)
* Sample project source code (lincolnthree, 14:31:53)
* AGREED: ozizka will move the sample apps to new github repo
(ozizka, 14:40:36)
* Next steps for everyone (lincolnthree, 14:42:41)
* I plan on finishing the logging refactor and pom cleanup
(lincolnthree, 14:43:04)
* I plan to finish up the dynamic groovy loading (a unit test for the
loader and some improvements to the graph sorter unit test at a
minium) (jsightler, 14:44:01)
* Then I plan to move on to blacklist work (jsightler, 14:44:13)
* Creating the basic windup rules in current framework (ozizka,
14:45:04)
* Check the legacy api for the plugin and create generic one if the
current is not generic enough. (ozizka, 14:46:11)
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-06-11-13.56.html
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-06-11-13.56.txt
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-06-11-13.56.log.html
--
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/20140611/b8807573/attachment-0001.html
From ozizka at redhat.com Thu Jun 12 08:03:13 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 12 Jun 2014 14:03:13 +0200
Subject: [windup-dev] Nested rules alternative?
Message-ID: <53999701.9060701@redhat.com>
Nested iterations create verbose rules with a lot of boilerplate.
Maybe the iteration could be over tuples of vertices.
Eg. in DiscoverJavaFilesCP, instead of
forEach( windupConf )
...
...
............
.....
forEach( javaFile )
we could query to get
[ { windupConf, javaFile },
{ windupConf, javaFile }
... ]
And iterate over that.
Anyone investigated this? IIRC from the Gremlin tutorial, this is possible.
Ondra
From itewksbu at redhat.com Mon Jun 16 10:07:39 2014
From: itewksbu at redhat.com (Ian Tewksbury)
Date: Mon, 16 Jun 2014 10:07:39 -0400 (EDT)
Subject: [windup-dev] Windup API for Eclipse Plugin Suggesitons
In-Reply-To: <1995625158.18898713.1402925320065.JavaMail.zimbra@redhat.com>
Message-ID: <1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com>
All,
Pete asked me to send out some of the ideas I have had about what the Eclipse plugin would like to see from the Windup core project as far as API goes.
ProgressMonitor
I would suggest basing this off the Eclipse IProgressMonitor API. I do not think it would make sense to actually use the Eclipse API because then Windup would be dependent on Eclipse. But if Windup had a similar interface I could use it to convert form a Windup ProgressMonitor to an Eclipse IProgressMonitor and report status back to the user. For Windup's long running actions this is very important.
WinupdEngine
I think it is important a single instance of the Windup Engine is reusable and can be run multiple times on the same project or on different projects. But if for whatever reason it is only one time use only that needs to be well documented in the API. Currently with legacy windup I only create one copy of the Engine
WindupEngine#setSettings(WindupEnvironment env) - set the windup options
WindupEngine#process(File parentProject, ProgressMonitor monitor) - runs windup on a parent folder and generates all the metadata
WindupEngine#generateReport(File parentProject, ProgressMonitor monitor) - generates a windup report based on all the metadata that is created by the #process(File parentFolder). This could either error out if the parentFolder has not yet been processed or could automatically process it
WindupEngine#getRuleMatches(File file) - Should return a list of RuleMatch objects, one for every rule match on a given file that can then be used to access any needed information about that rule match determined from all of the generated metadata
RuleMatch
This should be the class that is used to give API users all the information that was determined about a given resource. I would suggest most of this information if not all of it be lazily loaded and not pre populated. I do not know what your plan is for the storage of the windup model you will build on a given project. I hope there is some plan to not just keep it all in memory all the time and there will be some sort of file backend. An application like Eclipse is already a memory hog, to have to store the possibly infinite size of the windup model for all the projects in the workspace in memory all the time could get way out of proportion quickly. My suggestion would be this model would get saved to disk and then classes like the RuleMatch could query the model which would in turn query the disk for information. At the very least if the model is not saved to disk, then at least text and description from rules should only be loaded from disk when requested. So when loading a custom rule you have to load the matcher from disk as you process, but no need to load the description or other information until someone actually requests it, and even then that information should not be kept in memory by windup when requested, it should be returned and forgotten. I could go on an on on this subject, and it maybe a topic for another email or discussion at some point, but wanted to lay down some of my suggestions as it relates to this API.
I would also assume that the report generator for Winup would be using this same API to generate the report. I see the Windup Report generator and the Eclipse plugin as siblings, both using the same API to display the same information in different ways.
RuleMatch#getTitle() - a short description title of the match
RuleMatch#getLongDescription() - a more verbose description of the match. this could possible contain some level of markup/simple html for basic formatting
RuleMatch#getAdditionalReadingLinks() - returns list of links to externally extensible information relevant to the match
RuleMatch#getLocation() - returns a location object that will contain the line number and character start and end locations on that line of the match. If the match if for the entire file there should be some way of describing that as well.
RuleMatch#getCategory() - I am guessing rules will be provided in sets, JEE, WebSphere, Wildfly, or something that groups rules together in logical sets, this would be nice for reporting
RuleMatch#getSeverity() - I would suggest a three level system, info, warning, error.
RuleMatch#getFix() - Should return a block of text that can replace the matched block of text as a quick fix for the match. If you want to get really fancy these fixes should be able to match on parts of the match and inject them into the quick fix block. EX: if replacing one method call with another and there are parameters being passed the fix should be able to have some way of referencing those parameters so it can use them in its fix. This would all have to be done on the Windup side and likely all programmaticly by giving the rule writers access to the source they matched on so they can parse it for use in their fix code
----------------------
That is all I can think of for now. I hope this helps describe the kind of things Eclipse will be looking for in terms of API.
Blue Skies,
~Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140616/d01fab15/attachment.html
From lincolnbaxter at gmail.com Mon Jun 16 16:13:07 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Mon, 16 Jun 2014 16:13:07 -0400
Subject: [windup-dev] Nested rules alternative?
In-Reply-To: <53999701.9060701@redhat.com>
References: <53999701.9060701@redhat.com>
Message-ID: <CAEp_U4GK-aA+USonruEh3qE_byQzX=J3oD59iFx=bQM+xH3_mw@mail.gmail.com>
For the windup-configuration, i think the fastest answer is to do this:
https://issues.jboss.org/browse/WINDUP-87
On Thu, Jun 12, 2014 at 8:03 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Nested iterations create verbose rules with a lot of boilerplate.
> Maybe the iteration could be over tuples of vertices.
> Eg. in DiscoverJavaFilesCP, instead of
>
> forEach( windupConf )
> ...
> ...
> ............
> .....
> forEach( javaFile )
>
> we could query to get
> [ { windupConf, javaFile },
> { windupConf, javaFile }
> ... ]
>
> And iterate over that.
> Anyone investigated this? IIRC from the Gremlin tutorial, this is possible.
>
> 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/20140616/231cb46d/attachment.html
From ozizka at redhat.com Tue Jun 17 05:51:02 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 17 Jun 2014 11:51:02 +0200
Subject: [windup-dev] Nested rules alternative?
In-Reply-To: <CAEp_U4GK-aA+USonruEh3qE_byQzX=J3oD59iFx=bQM+xH3_mw@mail.gmail.com>
References: <53999701.9060701@redhat.com>
<CAEp_U4GK-aA+USonruEh3qE_byQzX=J3oD59iFx=bQM+xH3_mw@mail.gmail.com>
Message-ID: <53A00F86.6090509@redhat.com>
That solves only the cases when we really iterate over singleton.
For nested iterations, we will still have a lot of boilerplate....
On 16.6.2014 22:13, Lincoln Baxter, III wrote:
> For the windup-configuration, i think the fastest answer is to do
> this: https://issues.jboss.org/browse/WINDUP-87
>
>
> On Thu, Jun 12, 2014 at 8:03 AM, Ondrej Zizka <ozizka at redhat.com
> <mailto:ozizka at redhat.com>> wrote:
>
> Nested iterations create verbose rules with a lot of boilerplate.
> Maybe the iteration could be over tuples of vertices.
> Eg. in DiscoverJavaFilesCP, instead of
>
> forEach( windupConf )
> ...
> ...
> ............
> .....
> forEach( javaFile )
>
> we could query to get
> [ { windupConf, javaFile },
> { windupConf, javaFile }
> ... ]
>
> And iterate over that.
> Anyone investigated this? IIRC from the Gremlin tutorial, this is
> possible.
>
> 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/20140617/e85bdc59/attachment.html
From ozizka at redhat.com Tue Jun 17 19:16:49 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 18 Jun 2014 01:16:49 +0200
Subject: [windup-dev] Windup API for Eclipse Plugin Suggesitons
In-Reply-To: <1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com>
References: <1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com>
Message-ID: <53A0CC61.6060505@redhat.com>
Just few notes, inline.
On 16.6.2014 16:07, Ian Tewksbury wrote:
> All,
>
> Pete asked me to send out some of the ideas I have had about what the
> Eclipse plugin would like to see from the Windup core project as far
> as API goes.
>
> *ProgressMonitor*
>
> I would suggest basing this off the Eclipse IProgressMonitor API. I do
> not think it would make sense to actually use the Eclipse API because
> then Windup would be dependent on Eclipse. But if Windup had a similar
> interface I could use it to convert form a Windup ProgressMonitor to
> an Eclipse IProgressMonitor and report status back to the user. For
> Windup's long running actions this is very important.
By nature, the engine core can't tell what the progress is, other than
number of processed vs. remaining rules.
The rules might provide some metadata about how long they expect to run.
But they don't know until the previous rules are done.
So I guess this will be a bit of guesstimate - perhaps based on some
simple value based on "typical" duration, given by rules as metadata.
>
> *WinupdEngine*
>
> I think it is important a single instance of the Windup Engine is
> reusable and can be run multiple times on the same project or on
> different projects. But if for whatever reason it is only one time use
> only that needs to be well documented in the API. Currently with
> legacy windup I only create one copy of the Engine
>
> WindupEngine#setSettings(WindupEnvironment env) - set the windup options
>
> WindupEngine#process(File parentProject, ProgressMonitor monitor) -
> runs windup on a parent folder and generates all the metadata
Looks like a subset of input. So this would fill one app dir to input
and run, up to, excluding, the report phase.
> WindupEngine#generateReport(File parentProject, ProgressMonitor
> monitor) - generates a windup report based on all the metadata that is
> created by the #process(File parentFolder). This could either error
> out if the parentFolder has not yet been processed or could
> automatically process it
This might need change in current runner, to resume from the REPORTING
phase.
> WindupEngine#getRuleMatches(File file) - Should return a list of
> RuleMatch objects, one for every rule match on a given file that can
> then be used to access any needed information about that rule match
> determined from all of the generated metadata
That would probably be a matter of a query to the graph, in the ideal case.
>
> *RuleMatch*
> *
> *
> This should be the class that is used to give API users all the
> information that was determined about a given resource. I would
> suggest most of this information if not all of it be lazily loaded and
> not pre populated. I do not know what your plan is for the storage of
> the windup model you will build on a given project. I hope there is
> some plan to not just keep it all in memory all the time and there
> will be some sort of file backend. An application like Eclipse is
> already a memory hog, to have to store the possibly infinite size of
> the windup model for all the projects in the workspace in memory all
> the time could get way out of proportion quickly. My suggestion would
> be this model would get saved to disk and then classes like the
> RuleMatch could query the model which would in turn query the disk for
> information. At the very least if the model is not saved to disk, then
> at least text and description from rules should only be loaded from
> disk when requested. So when loading a custom rule you have to load
> the matcher from disk as you process, but no need to load the
> description or other information until someone actually requests it,
> and even then that information should not be kept in memory by windup
> when requested, it should be returned and forgotten. I could go on an
> on on this subject, and it maybe a topic for another email or
> discussion at some point, but wanted to lay down some of my
> suggestions as it relates to this API.
>
> I would also assume that the report generator for Winup would be using
> this same API to generate the report. I see the Windup Report
> generator and the Eclipse plugin as siblings, both using the same API
> to display the same information in different ways.
>
> RuleMatch#getTitle() - a short description title of the match
>
> RuleMatch#getLongDescription() - a more verbose description of the
> match. this could possible contain some level of markup/simple html
> for basic formatting
>
> RuleMatch#getAdditionalReadingLinks() - returns list of links to
> externally extensible information relevant to the match
>
> RuleMatch#getLocation() - returns a location object that will contain
> the line number and character start and end locations on that line of
> the match. If the match if for the entire file there should be some
> way of describing that as well.
>
> RuleMatch#getCategory() - I am guessing rules will be provided in
> sets, JEE, WebSphere, Wildfly, or something that groups rules together
> in logical sets, this would be nice for reporting
>
> RuleMatch#getSeverity() - I would suggest a three level system, info,
> warning, error.
>
> RuleMatch#getFix() - Should return a block of text that can replace
> the matched block of text as a quick fix for the match. If you want to
> get really fancy these fixes should be able to match on parts of the
> match and inject them into the quick fix block. EX: if replacing one
> method call with another and there are parameters being passed the fix
> should be able to have some way of referencing those parameters so it
> can use them in its fix. This would all have to be done on the Windup
> side and likely all programmaticly by giving the rule writers access
> to the source they matched on so they can parse it for use in their
> fix code
This should become part of the graph model. Perhaps not directly in a
FramedVertex. Could need some DTO to be prepared for this purpose.
Ondra
>
> ----------------------
>
> That is all I can think of for now. I hope this helps describe the
> kind of things Eclipse will be looking for in terms of API.
>
> Blue Skies,
> ~Ian
>
>
> _______________________________________________
> 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/20140618/e8730a71/attachment-0001.html
From ozizka at redhat.com Wed Jun 18 09:30:36 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 18 Jun 2014 15:30:36 +0200
Subject: [windup-dev] Windup API for Eclipse Plugin Suggesitons
In-Reply-To: <53A0CC61.6060505@redhat.com>
References: <1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com>
<53A0CC61.6060505@redhat.com>
Message-ID: <53A1947C.9010305@redhat.com>
Copied to WINDUP-91
On 18.6.2014 01:16, Ondrej Zizka wrote:
> Just few notes, inline.
>
> On 16.6.2014 16:07, Ian Tewksbury wrote:
>> All,
>>
>> Pete asked me to send out some of the ideas I have had about what the
>> Eclipse plugin would like to see from the Windup core project as far
>> as API goes.
>>
>> *ProgressMonitor*
>>
>> I would suggest basing this off the Eclipse IProgressMonitor API. I
>> do not think it would make sense to actually use the Eclipse API
>> because then Windup would be dependent on Eclipse. But if Windup had
>> a similar interface I could use it to convert form a Windup
>> ProgressMonitor to an Eclipse IProgressMonitor and report status back
>> to the user. For Windup's long running actions this is very important.
> By nature, the engine core can't tell what the progress is, other than
> number of processed vs. remaining rules.
> The rules might provide some metadata about how long they expect to run.
> But they don't know until the previous rules are done.
> So I guess this will be a bit of guesstimate - perhaps based on some
> simple value based on "typical" duration, given by rules as metadata.
>
>>
>> *WinupdEngine*
>>
>> I think it is important a single instance of the Windup Engine is
>> reusable and can be run multiple times on the same project or on
>> different projects. But if for whatever reason it is only one time
>> use only that needs to be well documented in the API. Currently with
>> legacy windup I only create one copy of the Engine
>>
>> WindupEngine#setSettings(WindupEnvironment env) - set the windup options
>>
>> WindupEngine#process(File parentProject, ProgressMonitor monitor) -
>> runs windup on a parent folder and generates all the metadata
> Looks like a subset of input. So this would fill one app dir to input
> and run, up to, excluding, the report phase.
>> WindupEngine#generateReport(File parentProject, ProgressMonitor
>> monitor) - generates a windup report based on all the metadata that
>> is created by the #process(File parentFolder). This could either
>> error out if the parentFolder has not yet been processed or could
>> automatically process it
> This might need change in current runner, to resume from the REPORTING
> phase.
>
>> WindupEngine#getRuleMatches(File file) - Should return a list of
>> RuleMatch objects, one for every rule match on a given file that can
>> then be used to access any needed information about that rule match
>> determined from all of the generated metadata
> That would probably be a matter of a query to the graph, in the ideal
> case.
>
>>
>> *RuleMatch*
>> *
>> *
>> This should be the class that is used to give API users all the
>> information that was determined about a given resource. I would
>> suggest most of this information if not all of it be lazily loaded
>> and not pre populated. I do not know what your plan is for the
>> storage of the windup model you will build on a given project. I hope
>> there is some plan to not just keep it all in memory all the time and
>> there will be some sort of file backend. An application like Eclipse
>> is already a memory hog, to have to store the possibly infinite size
>> of the windup model for all the projects in the workspace in memory
>> all the time could get way out of proportion quickly. My suggestion
>> would be this model would get saved to disk and then classes like the
>> RuleMatch could query the model which would in turn query the disk
>> for information. At the very least if the model is not saved to disk,
>> then at least text and description from rules should only be loaded
>> from disk when requested. So when loading a custom rule you have to
>> load the matcher from disk as you process, but no need to load the
>> description or other information until someone actually requests it,
>> and even then that information should not be kept in memory by windup
>> when requested, it should be returned and forgotten. I could go on an
>> on on this subject, and it maybe a topic for another email or
>> discussion at some point, but wanted to lay down some of my
>> suggestions as it relates to this API.
>>
>> I would also assume that the report generator for Winup would be
>> using this same API to generate the report. I see the Windup Report
>> generator and the Eclipse plugin as siblings, both using the same API
>> to display the same information in different ways.
>>
>> RuleMatch#getTitle() - a short description title of the match
>>
>> RuleMatch#getLongDescription() - a more verbose description of the
>> match. this could possible contain some level of markup/simple html
>> for basic formatting
>>
>> RuleMatch#getAdditionalReadingLinks() - returns list of links to
>> externally extensible information relevant to the match
>>
>> RuleMatch#getLocation() - returns a location object that will contain
>> the line number and character start and end locations on that line of
>> the match. If the match if for the entire file there should be some
>> way of describing that as well.
>>
>> RuleMatch#getCategory() - I am guessing rules will be provided in
>> sets, JEE, WebSphere, Wildfly, or something that groups rules
>> together in logical sets, this would be nice for reporting
>>
>> RuleMatch#getSeverity() - I would suggest a three level system, info,
>> warning, error.
>>
>> RuleMatch#getFix() - Should return a block of text that can replace
>> the matched block of text as a quick fix for the match. If you want
>> to get really fancy these fixes should be able to match on parts of
>> the match and inject them into the quick fix block. EX: if replacing
>> one method call with another and there are parameters being passed
>> the fix should be able to have some way of referencing those
>> parameters so it can use them in its fix. This would all have to be
>> done on the Windup side and likely all programmaticly by giving the
>> rule writers access to the source they matched on so they can parse
>> it for use in their fix code
> This should become part of the graph model. Perhaps not directly in a
> FramedVertex. Could need some DTO to be prepared for this purpose.
>
> Ondra
>>
>> ----------------------
>>
>> That is all I can think of for now. I hope this helps describe the
>> kind of things Eclipse will be looking for in terms of API.
>>
>> Blue Skies,
>> ~Ian
>>
>>
>> _______________________________________________
>> 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/20140618/29e87d09/attachment.html
From lincolnbaxter at gmail.com Wed Jun 18 11:22:12 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 18 Jun 2014 11:22:12 -0400
Subject: [windup-dev] Windup meeting minutes 2014-06-18
Message-ID: <CAEp_U4FjyNn0SwD_YSWsUP7U-vMX4-Yc+jwzUWjyPveiHZ3d+A@mail.gmail.com>
No major updates. The groovy rules prototype is functional and we have
identified/fixed a number of issues that were blocking us.
We are continuing to work on rules prototypes and functionality buildout
using the new architecture.
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-06-18-13.46.html
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-06-18-13.46.txt
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup.2014-06-18-13.46.log.html
--
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/20140618/2c1b6902/attachment.html
From lincolnbaxter at gmail.com Thu Jun 19 00:20:24 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Thu, 19 Jun 2014 00:20:24 -0400
Subject: [windup-dev] Windup API for Eclipse Plugin Suggesitons
In-Reply-To: <53A0CC61.6060505@redhat.com>
References: <1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com>
<53A0CC61.6060505@redhat.com>
Message-ID: <CAEp_U4G_pv4Qc=uOUoc3jpDP=kXQy12Bt+X-cdm+TW1yH9XObg@mail.gmail.com>
>
> By nature, the engine core can't tell what the progress is, other than
> number of processed vs. remaining rules.
That might actually be enough.
On Tue, Jun 17, 2014 at 7:16 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Just few notes, inline.
>
>
> On 16.6.2014 16:07, Ian Tewksbury wrote:
>
> All,
>
> Pete asked me to send out some of the ideas I have had about what the
> Eclipse plugin would like to see from the Windup core project as far as API
> goes.
>
> *ProgressMonitor*
>
> I would suggest basing this off the Eclipse IProgressMonitor API. I do
> not think it would make sense to actually use the Eclipse API because then
> Windup would be dependent on Eclipse. But if Windup had a similar interface
> I could use it to convert form a Windup ProgressMonitor to an Eclipse
> IProgressMonitor and report status back to the user. For Windup's long
> running actions this is very important.
>
> By nature, the engine core can't tell what the progress is, other than
> number of processed vs. remaining rules.
> The rules might provide some metadata about how long they expect to run.
> But they don't know until the previous rules are done.
> So I guess this will be a bit of guesstimate - perhaps based on some
> simple value based on "typical" duration, given by rules as metadata.
>
>
>
> *WinupdEngine*
>
> I think it is important a single instance of the Windup Engine is
> reusable and can be run multiple times on the same project or on different
> projects. But if for whatever reason it is only one time use only that
> needs to be well documented in the API. Currently with legacy windup I only
> create one copy of the Engine
>
> WindupEngine#setSettings(WindupEnvironment env) - set the windup options
>
> WindupEngine#process(File parentProject, ProgressMonitor monitor) - runs
> windup on a parent folder and generates all the metadata
>
> Looks like a subset of input. So this would fill one app dir to input and
> run, up to, excluding, the report phase.
>
> WindupEngine#generateReport(File parentProject, ProgressMonitor monitor)
> - generates a windup report based on all the metadata that is created by
> the #process(File parentFolder). This could either error out if the
> parentFolder has not yet been processed or could automatically process it
>
> This might need change in current runner, to resume from the REPORTING
> phase.
>
>
> WindupEngine#getRuleMatches(File file) - Should return a list of
> RuleMatch objects, one for every rule match on a given file that can then
> be used to access any needed information about that rule match determined
> from all of the generated metadata
>
> That would probably be a matter of a query to the graph, in the ideal case.
>
>
>
> *RuleMatch*
>
> This should be the class that is used to give API users all the
> information that was determined about a given resource. I would suggest
> most of this information if not all of it be lazily loaded and not pre
> populated. I do not know what your plan is for the storage of the windup
> model you will build on a given project. I hope there is some plan to not
> just keep it all in memory all the time and there will be some sort of file
> backend. An application like Eclipse is already a memory hog, to have to
> store the possibly infinite size of the windup model for all the projects
> in the workspace in memory all the time could get way out of proportion
> quickly. My suggestion would be this model would get saved to disk and then
> classes like the RuleMatch could query the model which would in turn query
> the disk for information. At the very least if the model is not saved to
> disk, then at least text and description from rules should only be loaded
> from disk when requested. So when loading a custom rule you have to load
> the matcher from disk as you process, but no need to load the description
> or other information until someone actually requests it, and even then that
> information should not be kept in memory by windup when requested, it
> should be returned and forgotten. I could go on an on on this subject, and
> it maybe a topic for another email or discussion at some point, but wanted
> to lay down some of my suggestions as it relates to this API.
>
> I would also assume that the report generator for Winup would be using
> this same API to generate the report. I see the Windup Report generator and
> the Eclipse plugin as siblings, both using the same API to display the same
> information in different ways.
>
> RuleMatch#getTitle() - a short description title of the match
>
> RuleMatch#getLongDescription() - a more verbose description of the
> match. this could possible contain some level of markup/simple html for
> basic formatting
>
> RuleMatch#getAdditionalReadingLinks() - returns list of links to
> externally extensible information relevant to the match
>
> RuleMatch#getLocation() - returns a location object that will contain
> the line number and character start and end locations on that line of the
> match. If the match if for the entire file there should be some way of
> describing that as well.
>
> RuleMatch#getCategory() - I am guessing rules will be provided in sets,
> JEE, WebSphere, Wildfly, or something that groups rules together in logical
> sets, this would be nice for reporting
>
> RuleMatch#getSeverity() - I would suggest a three level system, info,
> warning, error.
>
> RuleMatch#getFix() - Should return a block of text that can replace the
> matched block of text as a quick fix for the match. If you want to get
> really fancy these fixes should be able to match on parts of the match and
> inject them into the quick fix block. EX: if replacing one method call with
> another and there are parameters being passed the fix should be able to
> have some way of referencing those parameters so it can use them in its
> fix. This would all have to be done on the Windup side and likely all
> programmaticly by giving the rule writers access to the source they matched
> on so they can parse it for use in their fix code
>
> This should become part of the graph model. Perhaps not directly in a
> FramedVertex. Could need some DTO to be prepared for this purpose.
>
> Ondra
>
>
> ----------------------
>
> That is all I can think of for now. I hope this helps describe the kind
> of things Eclipse will be looking for in terms of API.
>
> Blue Skies,
> ~Ian
>
>
> _______________________________________________
> windup-dev mailing listwindup-dev at lists.jboss.orghttps://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/20140619/ebb6074a/attachment-0001.html
From ozizka at redhat.com Thu Jun 19 06:15:56 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 19 Jun 2014 12:15:56 +0200
Subject: [windup-dev] New branch - Modularize-03
Message-ID: <53A2B85C.7000907@redhat.com>
Hi,
1) merging didn't work for me (too many conflicts at once), so I
rebased, but instead of force push, I created a new branch, which is
current master + Modularize_new.
Is that git process ok for all?
2) Can we merge this into master now?
Regards,
Ondra
From itewksbu at redhat.com Thu Jun 19 08:40:22 2014
From: itewksbu at redhat.com (Ian Tewksbury)
Date: Thu, 19 Jun 2014 08:40:22 -0400 (EDT)
Subject: [windup-dev] Windup API for Eclipse Plugin Suggesitons
In-Reply-To: <CAEp_U4G_pv4Qc=uOUoc3jpDP=kXQy12Bt+X-cdm+TW1yH9XObg@mail.gmail.com>
References: <1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com>
<53A0CC61.6060505@redhat.com>
<CAEp_U4G_pv4Qc=uOUoc3jpDP=kXQy12Bt+X-cdm+TW1yH9XObg@mail.gmail.com>
Message-ID: <691586596.20334166.1403181622793.JavaMail.zimbra@redhat.com>
Any amount of progress that can be given is better then none. If the number of rules left to process is the best you got, that is better then an infinite progress bar.
Blue Skies,
~Ian
----- Original Message -----
From: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
To: "Windup-dev List" <windup-dev at lists.jboss.org>
Sent: Thursday, June 19, 2014 12:20:24 AM
Subject: Re: [windup-dev] Windup API for Eclipse Plugin Suggesitons
By nature, the engine core can't tell what the progress is, other than number of processed vs. remaining rules.
That might actually be enough.
On Tue, Jun 17, 2014 at 7:16 PM, Ondrej Zizka < ozizka at redhat.com > wrote:
<blockquote>
Just few notes, inline.
On 16.6.2014 16:07, Ian Tewksbury wrote:
<blockquote>
All,
Pete asked me to send out some of the ideas I have had about what the Eclipse plugin would like to see from the Windup core project as far as API goes.
ProgressMonitor
I would suggest basing this off the Eclipse IProgressMonitor API. I do not think it would make sense to actually use the Eclipse API because then Windup would be dependent on Eclipse. But if Windup had a similar interface I could use it to convert form a Windup ProgressMonitor to an Eclipse IProgressMonitor and report status back to the user. For Windup's long running actions this is very important.
</blockquote>
By nature, the engine core can't tell what the progress is, other than number of processed vs. remaining rules.
The rules might provide some metadata about how long they expect to run.
But they don't know until the previous rules are done.
So I guess this will be a bit of guesstimate - perhaps based on some simple value based on "typical" duration, given by rules as metadata.
<blockquote>
WinupdEngine
I think it is important a single instance of the Windup Engine is reusable and can be run multiple times on the same project or on different projects. But if for whatever reason it is only one time use only that needs to be well documented in the API. Currently with legacy windup I only create one copy of the Engine
WindupEngine#setSettings(WindupEnvironment env) - set the windup options
WindupEngine#process(File parentProject, ProgressMonitor monitor) - runs windup on a parent folder and generates all the metadata
</blockquote>
Looks like a subset of input. So this would fill one app dir to input and run, up to, excluding, the report phase.
<blockquote>
WindupEngine#generateReport(File parentProject, ProgressMonitor monitor) - generates a windup report based on all the metadata that is created by the #process(File parentFolder). This could either error out if the parentFolder has not yet been processed or could automatically process it
</blockquote>
This might need change in current runner, to resume from the REPORTING phase.
<blockquote>
WindupEngine#getRuleMatches(File file) - Should return a list of RuleMatch objects, one for every rule match on a given file that can then be used to access any needed information about that rule match determined from all of the generated metadata
</blockquote>
That would probably be a matter of a query to the graph, in the ideal case.
<blockquote>
RuleMatch
This should be the class that is used to give API users all the information that was determined about a given resource. I would suggest most of this information if not all of it be lazily loaded and not pre populated. I do not know what your plan is for the storage of the windup model you will build on a given project. I hope there is some plan to not just keep it all in memory all the time and there will be some sort of file backend. An application like Eclipse is already a memory hog, to have to store the possibly infinite size of the windup model for all the projects in the workspace in memory all the time could get way out of proportion quickly. My suggestion would be this model would get saved to disk and then classes like the RuleMatch could query the model which would in turn query the disk for information. At the very least if the model is not saved to disk, then at least text and description from rules should only be loaded from disk when requested. So when loading a custom rule you have to load the matcher from disk as you process, but no need to load the description or other information until someone actually requests it, and even then that information should not be kept in memory by windup when requested, it should be returned and forgotten. I could go on an on on this subject, and it maybe a topic for another email or discussion at some point, but wanted to lay down some of my suggestions as it relates to this API.
I would also assume that the report generator for Winup would be using this same API to generate the report. I see the Windup Report generator and the Eclipse plugin as siblings, both using the same API to display the same information in different ways.
RuleMatch#getTitle() - a short description title of the match
RuleMatch#getLongDescription() - a more verbose description of the match. this could possible contain some level of markup/simple html for basic formatting
RuleMatch#getAdditionalReadingLinks() - returns list of links to externally extensible information relevant to the match
RuleMatch#getLocation() - returns a location object that will contain the line number and character start and end locations on that line of the match. If the match if for the entire file there should be some way of describing that as well.
RuleMatch#getCategory() - I am guessing rules will be provided in sets, JEE, WebSphere, Wildfly, or something that groups rules together in logical sets, this would be nice for reporting
RuleMatch#getSeverity() - I would suggest a three level system, info, warning, error.
RuleMatch#getFix() - Should return a block of text that can replace the matched block of text as a quick fix for the match. If you want to get really fancy these fixes should be able to match on parts of the match and inject them into the quick fix block. EX: if replacing one method call with another and there are parameters being passed the fix should be able to have some way of referencing those parameters so it can use them in its fix. This would all have to be done on the Windup side and likely all programmaticly by giving the rule writers access to the source they matched on so they can parse it for use in their fix code
</blockquote>
This should become part of the graph model. Perhaps not directly in a FramedVertex. Could need some DTO to be prepared for this purpose.
Ondra
<blockquote>
----------------------
That is all I can think of for now. I hope this helps describe the kind of things Eclipse will be looking for in terms of API.
Blue Skies,
~Ian
_______________________________________________
windup-dev mailing list windup-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/windup-dev
</blockquote>
_______________________________________________
windup-dev mailing list
windup-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
</blockquote>
--
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/20140619/6afafc54/attachment.html
From ozizka at redhat.com Thu Jun 19 09:37:32 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 19 Jun 2014 15:37:32 +0200
Subject: [windup-dev] XML config -> extension?
Message-ID: <53A2E79C.70202@redhat.com>
Hi,
there's a lot of XML config related code in the core.
I suggest to put that to an extension, next to groovy. That's the exact
place it should be.
Ondra
From lincolnbaxter at gmail.com Thu Jun 19 13:37:10 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Thu, 19 Jun 2014 13:37:10 -0400
Subject: [windup-dev] XML config -> extension?
In-Reply-To: <53A2E79C.70202@redhat.com>
References: <53A2E79C.70202@redhat.com>
Message-ID: <CAEp_U4F9enhAjfMyiyDpVbK+H4aeH=V4kUDumw3hib1XCO=nwg@mail.gmail.com>
Yes. Agreed. This is the right thing to do.
On Thu, Jun 19, 2014 at 9:37 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Hi,
>
> there's a lot of XML config related code in the core.
> I suggest to put that to an extension, next to groovy. That's the exact
> place it should be.
>
> 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/20140619/e21e34d8/attachment.html
From ozizka at redhat.com Sun Jun 22 11:37:13 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Sun, 22 Jun 2014 17:37:13 +0200
Subject: [windup-dev] Proxy InvocationTargetException in FramedGraph.frame
Message-ID: <53A6F829.8080900@redhat.com>
Hi,
I've made few changes in a test, and seeing the
InvocationTargetException again.
See the WINDUP-95 issue and the WINDUP-95... branch.
Jess, could you please check that?
Regards,
Ondra
From ozizka at redhat.com Sun Jun 22 21:59:30 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Mon, 23 Jun 2014 03:59:30 +0200
Subject: [windup-dev] Indexes
Message-ID: <53A78A02.2020607@redhat.com>
Hi,
few things about indexing:
1) We add "archiveEntry" and "type" to the "search" index. Why those two?
2) Should each ruleset and its Model classes have separate index(es)? I
think so - could speed up looking up in different data domains.
3) The docs says the index has to be configured a priori. Where is it
configured?
4) I'll try to make the indexes discovered dynamically from the Model
classes metadata.
Ondra
PS: I don't like non-systemic plural "indices".
From ozizka at redhat.com Sun Jun 22 22:05:04 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Mon, 23 Jun 2014 04:05:04 +0200
Subject: [windup-dev] Branch XmlConfigSplit-3 // Re: XML config -> extension?
In-Reply-To: <CAEp_U4F9enhAjfMyiyDpVbK+H4aeH=V4kUDumw3hib1XCO=nwg@mail.gmail.com>
References: <53A2E79C.70202@redhat.com>
<CAEp_U4F9enhAjfMyiyDpVbK+H4aeH=V4kUDumw3hib1XCO=nwg@mail.gmail.com>
Message-ID: <53A78B50.5000907@redhat.com>
Hi,
The XmlConfigSplit-* branches push the core vs. rulesets split further.
Currently it's XmlConfigSplit-3.
Touches mainly config-xml and reporting.
Could you please review and ack merging?
Regards,
Ondra
On 19.6.2014 19:37, Lincoln Baxter, III wrote:
> Yes. Agreed. This is the right thing to do.
>
>
> On Thu, Jun 19, 2014 at 9:37 AM, Ondrej Zizka <ozizka at redhat.com
> <mailto:ozizka at redhat.com>> wrote:
>
> Hi,
>
> there's a lot of XML config related code in the core.
> I suggest to put that to an extension, next to groovy. That's the
> exact
> place it should be.
>
> 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/20140623/2ad914d8/attachment.html
From ozizka at redhat.com Mon Jun 23 05:58:51 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Mon, 23 Jun 2014 11:58:51 +0200
Subject: [windup-dev] Branch XmlConfigSplit-3 // Re: XML config ->
extension?
In-Reply-To: <53A78B50.5000907@redhat.com>
References: <53A2E79C.70202@redhat.com> <CAEp_U4F9enhAjfMyiyDpVbK+H4aeH=V4kUDumw3hib1XCO=nwg@mail.gmail.com>
<53A78B50.5000907@redhat.com>
Message-ID: <53A7FA5B.7000509@redhat.com>
I've added few more and rebased, now it's Xml...-4.
https://github.com/windup/windup/pull/104
Ondra
On 23.6.2014 04:05, Ondrej Zizka wrote:
> Hi,
>
> The XmlConfigSplit-* branches push the core vs. rulesets split further.
> Currently it's XmlConfigSplit-3.
> Touches mainly config-xml and reporting.
> Could you please review and ack merging?
>
> Regards,
> Ondra
>
>
>
> On 19.6.2014 19:37, Lincoln Baxter, III wrote:
>> Yes. Agreed. This is the right thing to do.
>>
>>
>> On Thu, Jun 19, 2014 at 9:37 AM, Ondrej Zizka <ozizka at redhat.com
>> <mailto:ozizka at redhat.com>> wrote:
>>
>> Hi,
>>
>> there's a lot of XML config related code in the core.
>> I suggest to put that to an extension, next to groovy. That's the
>> exact
>> place it should be.
>>
>> 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
>
>
>
> _______________________________________________
> 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/20140623/cec2404f/attachment.html
From ozizka at redhat.com Mon Jun 23 07:21:46 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Mon, 23 Jun 2014 13:21:46 +0200
Subject: [windup-dev] Forge module deps?
Message-ID: <53A80DCA.4060407@redhat.com>
Hi Lincoln,
could you please go through the dependencies and check if everything is ok,
and explain what are the correct ways to set up the deps?
E.g., there are some forge-addon deps, but not declared as provided.
Also, what to do if some other module only depends on an API? Should it
depend on the whole module?
Isn't it wrong to add the implementation to classpath too?
If it is, should API be a standalone module?
If not, is there a way to limit the exported classes? AS uses
module.xml, can that be used in Forge too?
Not the top priority thing, but I'd like to have this clear, can spare
me of some CL troubles in the future.
Thanks,
Ondra
From zizka at dynawest.cz Thu Jun 19 08:15:26 2014
From: zizka at dynawest.cz (Ing. Ondrej Zizka)
Date: Thu, 19 Jun 2014 14:15:26 +0200
Subject: [windup-dev] Eclipse API
Message-ID: <53A2D45E.3030008@dynawest.cz>
I've looked at the legacy API.
It's based on legacy Windup types tree, namely FileMetadata.
We could replace these subtypes in the existing API with
WindupVertexFrame subtypes.
Or restrict it on FileModel.
This approach could speed up morphing the Eclipse plugin to new Windup.
On the other hand, I belive that we will want the plugin to show also
non-file-based data, so some API like Ian described in WINDUP-91 would
be more appropriate - more general, and detached from the Model types.
Which is good, IMO.
We would need either manual conversion from graph content to that, or,
better, some mechanism for that.
Maybe some annotation based could do the work sufficiently - i.e.
provide some mapping from Frames to that RuleMatch API.
The question is, is the first approach worth creating as intermediate step?
Regads,
Ondra
From windup-dev at lists.jboss.org Mon Jun 23 07:39:30 2014
From: windup-dev at lists.jboss.org (windup-dev at lists.jboss.org)
Date: Mon, 23 Jun 2014 07:39:30 EDT
Subject: [windup-dev] Windup Dev Mailman Sync test
Message-ID: <1099202020.21403523600847.JavaMail.jive@jive-app01.app.mwc.hst.phx2.redhat.com>
Testing Mailmain sync.
This should go to The windup-dev Archives (http://lists.jboss.org/pipermail/windup-dev/)
Posted by forums
Original post: https://community.jboss.org/message/879015#879015
From ozizka at redhat.com Tue Jun 24 21:44:27 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 25 Jun 2014 03:44:27 +0200
Subject: [windup-dev] SelectionStack?
Message-ID: <53AA297B.50308@redhat.com>
Hi, shouldn't SelectionFactory be renamed to SelectionStack?
From ozizka at redhat.com Tue Jun 24 22:58:19 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 25 Jun 2014 04:58:19 +0200
Subject: [windup-dev] Iteration*Managers
Message-ID: <53AA3ACB.70402@redhat.com>
Hi,
what's the purpose of having IterationSelectionManager and
IterationPayloadManager?
I can only see Named~ and TypedNamed.
Wouldn't a simple method overload in SelectionFactory be enough for just
giving the option of type checking?
Or do we assume some other use case for that?
Also, the names don't fit - it's not manager, rather some kind of
filter, or getter.
Also, how about splitting SelectionFactory to VarStack and
CurrentPayloadManager? The variable stack and "current payload" seem to
be related only indirectly, by concept - at least in the current
implementation.
And lastly, I'd rename "current payload" to something like "cursor"
(resembling DB result iteration) or "current item" or "current element"
(which is how XSLT refers to iterated nodes). Payload rather evokes that
there's some wrapper around it, which is not.
Thanks,
Ondra
From ozizka at redhat.com Wed Jun 25 00:19:15 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 25 Jun 2014 06:19:15 +0200
Subject: [windup-dev] Iteration*Managers
In-Reply-To: <53AA3ACB.70402@redhat.com>
References: <53AA3ACB.70402@redhat.com>
Message-ID: <53AA4DC3.20807@redhat.com>
On 25.6.2014 04:58, Ondrej Zizka wrote:
> Hi,
>
> what's the purpose of having IterationSelectionManager and
> IterationPayloadManager?
> I can only see Named~ and TypedNamed.
> Wouldn't a simple method overload in SelectionFactory be enough for just
> giving the option of type checking?
> Or do we assume some other use case for that?
> Also, the names don't fit - it's not manager, rather some kind of
> filter, or getter.
Regarding IterationSelectionManager, it looks like it was created for
the Gremlin query API, which is based on Iteration as it assumes it
needs some initial vertices.
True?
>
> Also, how about splitting SelectionFactory to VarStack and
> CurrentPayloadManager? The variable stack and "current payload" seem to
> be related only indirectly, by concept - at least in the current
> implementation.
>
> And lastly, I'd rename "current payload" to something like "cursor"
> (resembling DB result iteration) or "current item" or "current element"
> (which is how XSLT refers to iterated nodes). Payload rather evokes that
> there's some wrapper around it, which is not.
>
> Thanks,
> Ondra
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From lincolnbaxter at gmail.com Wed Jun 25 02:04:49 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 25 Jun 2014 02:04:49 -0400
Subject: [windup-dev] Iteration*Managers
In-Reply-To: <53AA4DC3.20807@redhat.com>
References: <53AA3ACB.70402@redhat.com>
<53AA4DC3.20807@redhat.com>
Message-ID: <CAEp_U4FK0XxcSHfjSSeUO9wtfYQC9TzU-1p05Z3jyjQxTtPn0Q@mail.gmail.com>
IterationPayloadManager manages getting/setting of the current iteration
payload (e.g. the current cursor as you called it.)
IterationSelectionManager provides access to the specified selection
variable (e.g. something that was selected via GraphSearchConditionBuilder
(this name was initially "Selection" and we probably need to think about
changing the name to something else)
Regarding renaming SelectionFactory. I don't really like the name VarStack,
but I am open to suggestions. I think in looking at it again, it might even
need to be split into two types: "SelectionVariableStack" or
"IterationPayloadContext", because SelectionFactory currently does both of
those things, and they could actually be separate.
~Lincoln
On Wed, Jun 25, 2014 at 12:19 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
>
> On 25.6.2014 04:58, Ondrej Zizka wrote:
> > Hi,
> >
> > what's the purpose of having IterationSelectionManager and
> > IterationPayloadManager?
> > I can only see Named~ and TypedNamed.
> > Wouldn't a simple method overload in SelectionFactory be enough for just
> > giving the option of type checking?
> > Or do we assume some other use case for that?
> > Also, the names don't fit - it's not manager, rather some kind of
> > filter, or getter.
> Regarding IterationSelectionManager, it looks like it was created for
> the Gremlin query API, which is based on Iteration as it assumes it
> needs some initial vertices.
> True?
>
> >
> > Also, how about splitting SelectionFactory to VarStack and
> > CurrentPayloadManager? The variable stack and "current payload" seem to
> > be related only indirectly, by concept - at least in the current
> > implementation.
> >
> > And lastly, I'd rename "current payload" to something like "cursor"
> > (resembling DB result iteration) or "current item" or "current element"
> > (which is how XSLT refers to iterated nodes). Payload rather evokes that
> > there's some wrapper around it, which is not.
> >
> > 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
>
--
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/20140625/849a5d93/attachment.html
From lincolnbaxter at gmail.com Wed Jun 25 02:07:14 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 25 Jun 2014 02:07:14 -0400
Subject: [windup-dev] SelectionStack?
In-Reply-To: <53AA297B.50308@redhat.com>
References: <53AA297B.50308@redhat.com>
Message-ID: <CAEp_U4FXjqNrLRFKgj_esnL2tW1v_P3Q8rvbuK5pGT3jDAiq=w@mail.gmail.com>
See my comment on the previous email regarding this topic.
On Tue, Jun 24, 2014 at 9:44 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Hi, shouldn't SelectionFactory be renamed to SelectionStack?
> _______________________________________________
> 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/20140625/00b0943e/attachment.html
From lincolnbaxter at gmail.com Wed Jun 25 02:13:24 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 25 Jun 2014 02:13:24 -0400
Subject: [windup-dev] Eclipse API
In-Reply-To: <53A2D45E.3030008@dynawest.cz>
References: <53A2D45E.3030008@dynawest.cz>
Message-ID: <CAEp_U4GaGKX8FCPq5WS+RV_z8m7_3BJQrpT5xkP11aimFJn2cw@mail.gmail.com>
I think that using VertexFrame subtypes is the right idea, but I don't
think that we need to worry about the JBDS plugin yet at this point. I
don't see any technical blockers to doing the first part and then building
the API for the Eclipse plugin later, which would need to provide a more
specialized approach anyway and as you said, should not be tied to the
Model types.
I think that manual conversion is the way to go. I think that dealing with
annotations in this particular case would be too complicated for the
"benefit."
First approach I think is good. Though I guess it depends on what types
you're talking about specifically. Simply adding the types is not enough -
we also need to add rules that will populate the graph with these
types/interfaces.
~Lincoln
On Thu, Jun 19, 2014 at 8:15 AM, Ing. Ondrej Zizka <zizka at dynawest.cz>
wrote:
> I've looked at the legacy API.
> It's based on legacy Windup types tree, namely FileMetadata.
>
> We could replace these subtypes in the existing API with
> WindupVertexFrame subtypes.
> Or restrict it on FileModel.
> This approach could speed up morphing the Eclipse plugin to new Windup.
>
> On the other hand, I belive that we will want the plugin to show also
> non-file-based data, so some API like Ian described in WINDUP-91 would
> be more appropriate - more general, and detached from the Model types.
> Which is good, IMO.
> We would need either manual conversion from graph content to that, or,
> better, some mechanism for that.
> Maybe some annotation based could do the work sufficiently - i.e.
> provide some mapping from Frames to that RuleMatch API.
>
> The question is, is the first approach worth creating as intermediate step?
>
> Regads,
> 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/20140625/8468672a/attachment.html
From lincolnbaxter at gmail.com Wed Jun 25 02:16:02 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 25 Jun 2014 02:16:02 -0400
Subject: [windup-dev] Forge module deps?
In-Reply-To: <53A80DCA.4060407@redhat.com>
References: <53A80DCA.4060407@redhat.com>
Message-ID: <CAEp_U4G4DSbwCwsRUUT634f9zqA0GtwMKUcFkX4_NB2C6i9Agg@mail.gmail.com>
Sure, I'll take a look at this. I was in the middle of working on the POMs
but I had to stop due to the other refactoring work (I didn't want to get
in the way and cause lots of merge conflicts)
In the mean time, please read these two sections of the forge docs:
https://github.com/forge/core#re-use-functionality-from-other-addons
https://github.com/forge/core#what-scope-should-my-addon-dependencies-be
They should explain how dependencies should be added.
~Lincoln
On Mon, Jun 23, 2014 at 7:21 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Hi Lincoln,
>
> could you please go through the dependencies and check if everything is ok,
> and explain what are the correct ways to set up the deps?
>
> E.g., there are some forge-addon deps, but not declared as provided.
> Also, what to do if some other module only depends on an API? Should it
> depend on the whole module?
> Isn't it wrong to add the implementation to classpath too?
> If it is, should API be a standalone module?
> If not, is there a way to limit the exported classes? AS uses
> module.xml, can that be used in Forge too?
>
> Not the top priority thing, but I'd like to have this clear, can spare
> me of some CL troubles in the future.
>
> 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/20140625/4f21c346/attachment.html
From lincolnbaxter at gmail.com Wed Jun 25 02:16:54 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 25 Jun 2014 02:16:54 -0400
Subject: [windup-dev] Branch XmlConfigSplit-3 // Re: XML config ->
extension?
In-Reply-To: <53A7FA5B.7000509@redhat.com>
References: <53A2E79C.70202@redhat.com>
<CAEp_U4F9enhAjfMyiyDpVbK+H4aeH=V4kUDumw3hib1XCO=nwg@mail.gmail.com>
<53A78B50.5000907@redhat.com> <53A7FA5B.7000509@redhat.com>
Message-ID: <CAEp_U4HQWKaJBryB1e_5LK-HY5s7p17g29Qna0EUZe5jxBo8EA@mail.gmail.com>
I had made a few comments on github. Did you see them?
On Mon, Jun 23, 2014 at 5:58 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
> I've added few more and rebased, now it's Xml...-4.
> https://github.com/windup/windup/pull/104
>
> Ondra
>
>
>
> On 23.6.2014 04:05, Ondrej Zizka wrote:
>
> Hi,
>
> The XmlConfigSplit-* branches push the core vs. rulesets split further.
> Currently it's XmlConfigSplit-3.
> Touches mainly config-xml and reporting.
> Could you please review and ack merging?
>
> Regards,
> Ondra
>
>
>
> On 19.6.2014 19:37, Lincoln Baxter, III wrote:
>
> Yes. Agreed. This is the right thing to do.
>
>
> On Thu, Jun 19, 2014 at 9:37 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
>
>> Hi,
>>
>> there's a lot of XML config related code in the core.
>> I suggest to put that to an extension, next to groovy. That's the exact
>> place it should be.
>>
>> 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 listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
>
> _______________________________________________
> windup-dev mailing listwindup-dev at lists.jboss.orghttps://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/20140625/656b2fb1/attachment-0001.html
From lincolnbaxter at gmail.com Wed Jun 25 02:18:50 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 25 Jun 2014 02:18:50 -0400
Subject: [windup-dev] Indexes
In-Reply-To: <53A78A02.2020607@redhat.com>
References: <53A78A02.2020607@redhat.com>
Message-ID: <CAEp_U4HPXx03rJV37_LDDTF8xE3Jr=wcvYfJ2QcuXjAwnJDc3Q@mail.gmail.com>
Let's worry about indexing and performance later, when we know there is a
problem. If you want to add a few more indexes for the time being, that's
fine, but don't worry about making the index system extendible right now...
I'd focus on getting the groovy rules to work more and support more
features, and also work on getting the report generation working.
The indexes are created in:
/org.jboss.windup.graph:windup-graph-impl/src/main/java/org/jboss/windup/graph/GraphContextImpl.java
~Lincoln
On Sun, Jun 22, 2014 at 9:59 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Hi,
>
> few things about indexing:
>
> 1) We add "archiveEntry" and "type" to the "search" index. Why those two?
> 2) Should each ruleset and its Model classes have separate index(es)? I
> think so - could speed up looking up in different data domains.
> 3) The docs says the index has to be configured a priori. Where is it
> configured?
> 4) I'll try to make the indexes discovered dynamically from the Model
> classes metadata.
>
> Ondra
>
> PS: I don't like non-systemic plural "indices".
> _______________________________________________
> 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/20140625/d7a07148/attachment.html
From jsightle at redhat.com Wed Jun 25 09:36:58 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Wed, 25 Jun 2014 09:36:58 -0400
Subject: [windup-dev] Indexes
In-Reply-To: <CAEp_U4HPXx03rJV37_LDDTF8xE3Jr=wcvYfJ2QcuXjAwnJDc3Q@mail.gmail.com>
References: <53A78A02.2020607@redhat.com>
<CAEp_U4HPXx03rJV37_LDDTF8xE3Jr=wcvYfJ2QcuXjAwnJDc3Q@mail.gmail.com>
Message-ID: <53AAD07A.8090901@redhat.com>
"type" has to be indexed as a "search" field, otherwise our type
searches would become inordinately slow. Otherwise, I haven't seen where
this is a problem so far. I agree that in the long-run we need to pull
this from *Model metadata, though.
On 06/25/2014 02:18 AM, Lincoln Baxter, III wrote:
> Let's worry about indexing and performance later, when we know there
> is a problem. If you want to add a few more indexes for the time
> being, that's fine, but don't worry about making the index system
> extendible right now...
>
> I'd focus on getting the groovy rules to work more and support more
> features, and also work on getting the report generation working.
>
> The indexes are created in:
> /org.jboss.windup.graph:windup-graph-impl/src/main/java/org/jboss/windup/graph/GraphContextImpl.java
>
> ~Lincoln
>
>
> On Sun, Jun 22, 2014 at 9:59 PM, Ondrej Zizka <ozizka at redhat.com
> <mailto:ozizka at redhat.com>> wrote:
>
> Hi,
>
> few things about indexing:
>
> 1) We add "archiveEntry" and "type" to the "search" index. Why
> those two?
> 2) Should each ruleset and its Model classes have separate
> index(es)? I
> think so - could speed up looking up in different data domains.
> 3) The docs says the index has to be configured a priori. Where is it
> configured?
> 4) I'll try to make the indexes discovered dynamically from the Model
> classes metadata.
>
> Ondra
>
> PS: I don't like non-systemic plural "indices".
> _______________________________________________
> 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/20140625/07d1ddcc/attachment.html
From ozizka at redhat.com Wed Jun 25 21:04:19 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 26 Jun 2014 03:04:19 +0200
Subject: [windup-dev] Indexes
In-Reply-To: <53AAD07A.8090901@redhat.com>
References: <53A78A02.2020607@redhat.com> <CAEp_U4HPXx03rJV37_LDDTF8xE3Jr=wcvYfJ2QcuXjAwnJDc3Q@mail.gmail.com>
<53AAD07A.8090901@redhat.com>
Message-ID: <53AB7193.5000001@redhat.com>
Sure, long-term.
On 25.6.2014 15:36, Jess Sightler wrote:
> "type" has to be indexed as a "search" field, otherwise our type
> searches would become inordinately slow. Otherwise, I haven't seen
> where this is a problem so far. I agree that in the long-run we need
> to pull this from *Model metadata, though.
>
> On 06/25/2014 02:18 AM, Lincoln Baxter, III wrote:
>> Let's worry about indexing and performance later, when we know there
>> is a problem. If you want to add a few more indexes for the time
>> being, that's fine, but don't worry about making the index system
>> extendible right now...
>>
>> I'd focus on getting the groovy rules to work more and support more
>> features, and also work on getting the report generation working.
>>
>> The indexes are created in:
>> /org.jboss.windup.graph:windup-graph-impl/src/main/java/org/jboss/windup/graph/GraphContextImpl.java
>>
>> ~Lincoln
>>
>>
>> On Sun, Jun 22, 2014 at 9:59 PM, Ondrej Zizka <ozizka at redhat.com
>> <mailto:ozizka at redhat.com>> wrote:
>>
>> Hi,
>>
>> few things about indexing:
>>
>> 1) We add "archiveEntry" and "type" to the "search" index. Why
>> those two?
>> 2) Should each ruleset and its Model classes have separate
>> index(es)? I
>> think so - could speed up looking up in different data domains.
>> 3) The docs says the index has to be configured a priori. Where is it
>> configured?
>> 4) I'll try to make the indexes discovered dynamically from the Model
>> classes metadata.
>>
>> Ondra
>>
>> PS: I don't like non-systemic plural "indices".
>> _______________________________________________
>> 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/20140626/c1732eac/attachment.html
From ozizka at redhat.com Wed Jun 25 21:11:15 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 26 Jun 2014 03:11:15 +0200
Subject: [windup-dev] Branch XmlConfigSplit-3 // Re: XML config ->
extension?
In-Reply-To: <CAEp_U4HQWKaJBryB1e_5LK-HY5s7p17g29Qna0EUZe5jxBo8EA@mail.gmail.com>
References: <53A2E79C.70202@redhat.com> <CAEp_U4F9enhAjfMyiyDpVbK+H4aeH=V4kUDumw3hib1XCO=nwg@mail.gmail.com> <53A78B50.5000907@redhat.com>
<53A7FA5B.7000509@redhat.com>
<CAEp_U4HQWKaJBryB1e_5LK-HY5s7p17g29Qna0EUZe5jxBo8EA@mail.gmail.com>
Message-ID: <53AB7333.7050605@redhat.com>
Not until now. But I believe all is sorted out now.
On 25.6.2014 08:16, Lincoln Baxter, III wrote:
> I had made a few comments on github. Did you see them?
>
>
> On Mon, Jun 23, 2014 at 5:58 AM, Ondrej Zizka <ozizka at redhat.com
> <mailto:ozizka at redhat.com>> wrote:
>
> I've added few more and rebased, now it's Xml...-4.
> https://github.com/windup/windup/pull/104
>
> Ondra
>
>
>
> On 23.6.2014 04:05, Ondrej Zizka wrote:
>> Hi,
>>
>> The XmlConfigSplit-* branches push the core vs. rulesets split
>> further.
>> Currently it's XmlConfigSplit-3.
>> Touches mainly config-xml and reporting.
>> Could you please review and ack merging?
>>
>> Regards,
>> Ondra
>>
>>
>>
>> On 19.6.2014 19:37, Lincoln Baxter, III wrote:
>>> Yes. Agreed. This is the right thing to do.
>>>
>>>
>>> On Thu, Jun 19, 2014 at 9:37 AM, Ondrej Zizka <ozizka at redhat.com
>>> <mailto:ozizka at redhat.com>> wrote:
>>>
>>> Hi,
>>>
>>> there's a lot of XML config related code in the core.
>>> I suggest to put that to an extension, next to groovy.
>>> That's the exact
>>> place it should be.
>>>
>>> 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 <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/20140626/ea9d6837/attachment-0001.html
From ozizka at redhat.com Wed Jun 25 21:39:52 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 26 Jun 2014 03:39:52 +0200
Subject: [windup-dev] Iteration*Managers
In-Reply-To: <CAEp_U4FK0XxcSHfjSSeUO9wtfYQC9TzU-1p05Z3jyjQxTtPn0Q@mail.gmail.com>
References: <53AA3ACB.70402@redhat.com> <53AA4DC3.20807@redhat.com>
<CAEp_U4FK0XxcSHfjSSeUO9wtfYQC9TzU-1p05Z3jyjQxTtPn0Q@mail.gmail.com>
Message-ID: <53AB79E8.3060305@redhat.com>
On 25.6.2014 08:04, Lincoln Baxter, III wrote:
> IterationPayloadManager manages getting/setting of the current
> iteration payload (e.g. the current cursor as you called it.)
>
> IterationSelectionManager provides access to the specified selection
> variable (e.g. something that was selected via
> GraphSearchConditionBuilder (this name was initially "Selection" and
> we probably need to think about changing the name to something else)
It's rather some kind of view/projection than a manager - the
SelectionFactory / VarStack actually manages both.
And I ponder how many ways to get the frames based on a name can there
be. Can one var name lead to different set frames? If not, then that's
my point - if there's just one, then this layer is not necessary. Or do
I miss something?
>
> Regarding renaming SelectionFactory. I don't really like the name
> VarStack, but I am open to suggestions.
Well, I already renamed it to VarStack :) I hope you like it more than
SelectionFactory. More below.
> I think in looking at it again, it might even need to be split into
> two types: "SelectionVariableStack" or "IterationPayloadContext",
> because SelectionFactory currently does both of those things, and they
> could actually be separate.
Right. This would bring a need to drag 2 references around, so it might
need some object above it, but I think splitting it will be worth it, to
keep these two contracts decoupled.
The variables stack doesn't necessarily have to keep just sets of
frames. I think later we will use the same storage to store both list of
frames and other values - or not?
I can imagine users will need to store a string. Sure, they can store it
to the graph, too. Depends on how easy we make that.
That said, the structure could be:
<some clever name like>
-- VarStack <------ nothing?
-- PayloadKeeper <------ PayloadProjector?
Ondra
>
> ~Lincoln
>
>
> On Wed, Jun 25, 2014 at 12:19 AM, Ondrej Zizka <ozizka at redhat.com
> <mailto:ozizka at redhat.com>> wrote:
>
>
> On 25.6.2014 04:58, Ondrej Zizka wrote:
> > Hi,
> >
> > what's the purpose of having IterationSelectionManager and
> > IterationPayloadManager?
> > I can only see Named~ and TypedNamed.
> > Wouldn't a simple method overload in SelectionFactory be enough
> for just
> > giving the option of type checking?
> > Or do we assume some other use case for that?
> > Also, the names don't fit - it's not manager, rather some kind of
> > filter, or getter.
> Regarding IterationSelectionManager, it looks like it was created for
> the Gremlin query API, which is based on Iteration as it assumes it
> needs some initial vertices.
> True?
>
> >
> > Also, how about splitting SelectionFactory to VarStack and
> > CurrentPayloadManager? The variable stack and "current payload"
> seem to
> > be related only indirectly, by concept - at least in the current
> > implementation.
> >
> > And lastly, I'd rename "current payload" to something like "cursor"
> > (resembling DB result iteration) or "current item" or "current
> element"
> > (which is how XSLT refers to iterated nodes). Payload rather
> evokes that
> > there's some wrapper around it, which is not.
> >
> > 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
>
> _______________________________________________
> 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/20140626/5610e136/attachment.html
From ozizka at redhat.com Wed Jun 25 21:49:32 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 26 Jun 2014 03:49:32 +0200
Subject: [windup-dev] Iterations generalization?
Message-ID: <53AB7C2C.6020500@redhat.com>
I think users will also need to iterate over other sets than frames.
They might get some results from external services, or even just a list
of strings in the rule, e.g. to create 5 datasources hard-coded in their
rule - why not.
We might want to generalize the iteration code. In the future.
WDYT?
Ondra
From ozizka at redhat.com Wed Jun 25 22:20:45 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 26 Jun 2014 04:20:45 +0200
Subject: [windup-dev] Iteration*Managers
In-Reply-To: <53AB79E8.3060305@redhat.com>
References: <53AA3ACB.70402@redhat.com> <53AA4DC3.20807@redhat.com> <CAEp_U4FK0XxcSHfjSSeUO9wtfYQC9TzU-1p05Z3jyjQxTtPn0Q@mail.gmail.com>
<53AB79E8.3060305@redhat.com>
Message-ID: <53AB837D.8000800@redhat.com>
It seems that the interface could be reduced from
public interface IterationSelectionManager {
Iterable<WindupVertexFrame> getFrames(GraphRewrite event, VarStack
varStack);
}
to just
public interface FramesSelector {
Iterable<WindupVertexFrame> getFrames();
}
Because:
1) Has not much to do with iteration
2) the stack and the event do not necessarily have to be needed /
available at the time of calling getFrames(),
3) event is used just to get the context, which may be set in impl's
constructor (or injected?),
4) The variables stack should be accessible from the context, i.e.
somehow from the event. and if not, 3) applies here too.
WDYT?
Ondra
On 26.6.2014 03:39, Ondrej Zizka wrote:
> On 25.6.2014 08:04, Lincoln Baxter, III wrote:
>> IterationSelectionManager provides access to the specified selection
>> variable (e.g. something that was selected via
>> GraphSearchConditionBuilder (this name was initially "Selection" and
>> we probably need to think about changing the name to something else)
> It's rather some kind of view/projection than a manager - the
> SelectionFactory / VarStack actually manages both.
> And I ponder how many ways to get the frames based on a name can there
> be. Can one var name lead to different set frames? If not, then that's
> my point - if there's just one, then this layer is not necessary. Or
> do I miss something?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140626/dff17250/attachment.html
From ozizka at redhat.com Wed Jun 25 22:43:25 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 26 Jun 2014 04:43:25 +0200
Subject: [windup-dev] Pileline.select() to get a table /// Re: Nested rules
alternative?
In-Reply-To: <53999701.9060701@redhat.com>
References: <53999701.9060701@redhat.com>
Message-ID: <53AB88CD.7010103@redhat.com>
Good news: I found it. The select(...) creates the tuples in a form of
Row objects.
Problem is that our current API limits the output to Vertex as it frames
it later.
We could add support for the Row object and create RowFramed which would
hold the tuples of framed vertexes.
Ondra
On 12.6.2014 14:03, Ondrej Zizka wrote:
> Nested iterations create verbose rules with a lot of boilerplate.
> Maybe the iteration could be over tuples of vertices.
> Eg. in DiscoverJavaFilesCP, instead of
>
> forEach( windupConf )
> ...
> ...
> ............
> .....
> forEach( javaFile )
>
> we could query to get
> [ { windupConf, javaFile },
> { windupConf, javaFile }
> ... ]
>
> And iterate over that.
> Anyone investigated this? IIRC from the Gremlin tutorial, this is possible.
>
> Ondra
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Thu Jun 26 01:31:55 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 26 Jun 2014 07:31:55 +0200
Subject: [windup-dev] Pileline.select() to get a table /// Re: Nested
rules alternative?
In-Reply-To: <53AB88CD.7010103@redhat.com>
References: <53999701.9060701@redhat.com> <53AB88CD.7010103@redhat.com>
Message-ID: <53ABB04B.5070105@redhat.com>
Here's a nice article:
https://github.com/tinkerpop/gremlin/wiki/Pattern-Match-Pattern
Ondra
On 26.6.2014 04:43, Ondrej Zizka wrote:
> Good news: I found it. The select(...) creates the tuples in a form of
> Row objects.
> Problem is that our current API limits the output to Vertex as it frames
> it later.
> We could add support for the Row object and create RowFramed which would
> hold the tuples of framed vertexes.
>
> Ondra
>
>
> On 12.6.2014 14:03, Ondrej Zizka wrote:
>> Nested iterations create verbose rules with a lot of boilerplate.
>> Maybe the iteration could be over tuples of vertices.
>> Eg. in DiscoverJavaFilesCP, instead of
>>
>> forEach( windupConf )
>> ...
>> ...
>> ............
>> .....
>> forEach( javaFile )
>>
>> we could query to get
>> [ { windupConf, javaFile },
>> { windupConf, javaFile }
>> ... ]
>>
>> And iterate over that.
>> Anyone investigated this? IIRC from the Gremlin tutorial, this is possible.
>>
>> 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 Thu Jun 26 17:09:47 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Thu, 26 Jun 2014 23:09:47 +0200
Subject: [windup-dev] Iteration*Managers
In-Reply-To: <53AB837D.8000800@redhat.com>
References: <53AA3ACB.70402@redhat.com> <53AA4DC3.20807@redhat.com> <CAEp_U4FK0XxcSHfjSSeUO9wtfYQC9TzU-1p05Z3jyjQxTtPn0Q@mail.gmail.com> <53AB79E8.3060305@redhat.com>
<53AB837D.8000800@redhat.com>
Message-ID: <53AC8C1B.2040402@redhat.com>
Let's move this discussion to
https://issues.jboss.org/browse/WINDUP-97?jql=project%20%3D%20WINDUP
Ondra
On 26.6.2014 04:20, Ondrej Zizka wrote:
> It seems that the interface could be reduced from
>
> public interface IterationSelectionManager {
> Iterable<WindupVertexFrame> getFrames(GraphRewrite event, VarStack
> varStack);
> }
>
> to just
>
> public interface FramesSelector {
> Iterable<WindupVertexFrame> getFrames();
> }
>
> Because:
>
> 1) Has not much to do with iteration
> 2) the stack and the event do not necessarily have to be needed /
> available at the time of calling getFrames(),
> 3) event is used just to get the context, which may be set in impl's
> constructor (or injected?),
> 4) The variables stack should be accessible from the context, i.e.
> somehow from the event. and if not, 3) applies here too.
>
> WDYT?
>
> Ondra
>
>
>
> On 26.6.2014 03:39, Ondrej Zizka wrote:
>> On 25.6.2014 08:04, Lincoln Baxter, III wrote:
>>> IterationSelectionManager provides access to the specified selection
>>> variable (e.g. something that was selected via
>>> GraphSearchConditionBuilder (this name was initially "Selection" and
>>> we probably need to think about changing the name to something else)
>> It's rather some kind of view/projection than a manager - the
>> SelectionFactory / VarStack actually manages both.
>> And I ponder how many ways to get the frames based on a name can
>> there be. Can one var name lead to different set frames? If not, then
>> that's my point - if there's just one, then this layer is not
>> necessary. Or do I miss something?
>
>
>
> _______________________________________________
> 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/20140626/a9a03bb4/attachment-0001.html
From ozizka at redhat.com Thu Jun 26 22:05:01 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 27 Jun 2014 04:05:01 +0200
Subject: [windup-dev] GitHub wiki obsolete
Message-ID: <53ACD14D.5060905@redhat.com>
Hi all,
the github wiki in windup/windup is obsolete. It belongs to windup-legacy.
I'll try to move it there, and I'd like to start writing some info about
the current implementation.
Any tips on how to move? I thought it's a branch, but it's not. And I
don't see any "export wiki" option.
Ondra
From ozizka at redhat.com Thu Jun 26 22:24:34 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 27 Jun 2014 04:24:34 +0200
Subject: [windup-dev] GitHub wiki obsolete
In-Reply-To: <53ACD14D.5060905@redhat.com>
References: <53ACD14D.5060905@redhat.com>
Message-ID: <53ACD5E2.7040607@redhat.com>
Done: https://github.com/windup/windup-legacy/wiki
Now we can freely edit the new one.
Ondra
On 27.6.2014 04:05, Ondrej Zizka wrote:
> Hi all,
>
> the github wiki in windup/windup is obsolete. It belongs to windup-legacy.
> I'll try to move it there, and I'd like to start writing some info about
> the current implementation.
>
> Any tips on how to move? I thought it's a branch, but it's not. And I
> don't see any "export wiki" option.
>
> Ondra
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From lincolnbaxter at gmail.com Fri Jun 27 02:02:50 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 27 Jun 2014 02:02:50 -0400
Subject: [windup-dev] Branch XmlConfigSplit-3 // Re: XML config ->
extension?
In-Reply-To: <53AB7333.7050605@redhat.com>
References: <53A2E79C.70202@redhat.com>
<CAEp_U4F9enhAjfMyiyDpVbK+H4aeH=V4kUDumw3hib1XCO=nwg@mail.gmail.com>
<53A78B50.5000907@redhat.com> <53A7FA5B.7000509@redhat.com>
<CAEp_U4HQWKaJBryB1e_5LK-HY5s7p17g29Qna0EUZe5jxBo8EA@mail.gmail.com>
<53AB7333.7050605@redhat.com>
Message-ID: <CAEp_U4FrQAABJnX7=C-e=cvNHrkDdvhk_dc0JBMvLEibs5rdmw@mail.gmail.com>
Okay cool. Go ahead!
On Wed, Jun 25, 2014 at 9:11 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Not until now. But I believe all is sorted out now.
>
>
>
> On 25.6.2014 08:16, Lincoln Baxter, III wrote:
>
> I had made a few comments on github. Did you see them?
>
>
> On Mon, Jun 23, 2014 at 5:58 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
>
>> I've added few more and rebased, now it's Xml...-4.
>> https://github.com/windup/windup/pull/104
>>
>> Ondra
>>
>>
>>
>> On 23.6.2014 04:05, Ondrej Zizka wrote:
>>
>> Hi,
>>
>> The XmlConfigSplit-* branches push the core vs. rulesets split further.
>> Currently it's XmlConfigSplit-3.
>> Touches mainly config-xml and reporting.
>> Could you please review and ack merging?
>>
>> Regards,
>> Ondra
>>
>>
>>
>> On 19.6.2014 19:37, Lincoln Baxter, III wrote:
>>
>> Yes. Agreed. This is the right thing to do.
>>
>>
>> On Thu, Jun 19, 2014 at 9:37 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> there's a lot of XML config related code in the core.
>>> I suggest to put that to an extension, next to groovy. That's the exact
>>> place it should be.
>>>
>>> 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 listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>>
>>
>>
>>
>> _______________________________________________
>> windup-dev mailing listwindup-dev at lists.jboss.orghttps://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 listwindup-dev at lists.jboss.orghttps://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/20140627/67d9c4b3/attachment.html
From lincolnbaxter at gmail.com Fri Jun 27 02:03:39 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 27 Jun 2014 02:03:39 -0400
Subject: [windup-dev] Iterations generalization?
In-Reply-To: <53AB7C2C.6020500@redhat.com>
References: <53AB7C2C.6020500@redhat.com>
Message-ID: <CAEp_U4EPzW5nBPt-oxQqseCPWyM9FHW=5aM16Uzt5rFxu-TmXw@mail.gmail.com>
Hmmm possibly, but until we see a required use-case let's leave it as-is
and work on getting the rest of the system up and running :)
On Wed, Jun 25, 2014 at 9:49 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> I think users will also need to iterate over other sets than frames.
> They might get some results from external services, or even just a list
> of strings in the rule, e.g. to create 5 datasources hard-coded in their
> rule - why not.
> We might want to generalize the iteration code. In the future.
> 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/20140627/5993246a/attachment.html
From lincolnbaxter at gmail.com Fri Jun 27 02:14:48 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 27 Jun 2014 02:14:48 -0400
Subject: [windup-dev] GitHub wiki obsolete
In-Reply-To: <53ACD5E2.7040607@redhat.com>
References: <53ACD14D.5060905@redhat.com>
<53ACD5E2.7040607@redhat.com>
Message-ID: <CAEp_U4Er1nrSupkBxHp4SpZSbnL43Nqk34PsNqhhZk1GPMZ4_g@mail.gmail.com>
Thanks Ondra.
As a side note... if you feel the need to ask a question about "if you
should do something," please wait until we can talk about it before moving
forward :)
I have a few followup tasks. It seems like we should remove the rest of the
content from the windup/windup/wiki because there is information that is
misleading at this point. Could you please handle removing all non
windup-2.0 content, as well as placing a clear link on the top of the
windup/windup/wiki homepage that will send/link users to the
legacy-windup/wiki ? Be sure to include a message that clearly states the
old version can still be found at the new location.
Thank you!
Lincoln
On Thu, Jun 26, 2014 at 10:24 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> Done: https://github.com/windup/windup-legacy/wiki
>
> Now we can freely edit the new one.
>
> Ondra
>
>
>
>
> On 27.6.2014 04:05, Ondrej Zizka wrote:
> > Hi all,
> >
> > the github wiki in windup/windup is obsolete. It belongs to
> windup-legacy.
> > I'll try to move it there, and I'd like to start writing some info about
> > the current implementation.
> >
> > Any tips on how to move? I thought it's a branch, but it's not. And I
> > don't see any "export wiki" option.
> >
> > 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
>
--
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/20140627/4c56ad34/attachment.html