From lincolnbaxter at gmail.com Mon Mar 2 14:14:30 2015 From: lincolnbaxter at gmail.com (Lincoln Baxter, III) Date: Mon, 2 Mar 2015 14:14:30 -0500 Subject: [forge-dev] Roaster and type-resolving Message-ID: It looks like it's possible to implement proper type resolving fairly easily using the new JDT - we should consider using this: https://github.com/jsight/windup/blob/mbriskar_ast_tweaks/rules-java/api/src/main/java/org/jboss/windup/rules/apps/java/scan/provider/AnalyzeJavaFilesRuleProvider.java#L105 Then we could actually do things like query the known types on the project classpath and actually generate scaffolded from types in other projects / dependencies, etc. -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150302/47a2be3d/attachment.html From lincolnbaxter at gmail.com Tue Mar 3 11:10:04 2015 From: lincolnbaxter at gmail.com (Lincoln Baxter, III) Date: Tue, 3 Mar 2015 11:10:04 -0500 Subject: [forge-dev] Forge Meeting Minutes - 2015-03-03 Message-ID: Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-02-22.43.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-02-22.43.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-02-22.43.log.html Meeting summary --------------- * Agenda (gastaldi, 22:43:19) * Forge Tutorials (gastaldi, 22:44:43) * LINK: https://docs.google.com/document/d/11Y-zcl2-fp-Kxdq1wq8gM37_AUeWX6SQiYV65d7H5es/edit?usp=sharing (agoncal, 22:45:05) * ACTION: agoncal will send an email to the Forge ML/tweet asking for reviewers for the tutorial (gastaldi, 22:48:15) * ACTION: agoncal will start the next tutorial gently next week (gastaldi, 22:49:51) * Priority tasks (gastaldi, 22:53:17) * Removal of Forge 1 from JBDS is #1 priority (gastaldi, 22:59:34) * Upgrade JBDS plugin (and NetBeans/IntelliJ) to use addonCompatibilityStrategy (lincolnthree, 23:00:35) * Documentation improvement and website are both high priority (lincolnthree, 23:02:51) * ACTION: The Forge Team will release 2.15.0.Final still this week (gastaldi, 23:03:39) * ACTION: lincolnthree and gastaldi will review the latest website updates (gastaldi, 23:06:57) * Website (gastaldi, 23:07:28) * I have just received a new batch of changes from the designer that need review (lincolnthree, 23:08:25) * We need to update Redoculous to use the filesystem, not infinispan (lincolnthree, 23:08:38) * Site should be nearly done. Just have to make sure all of our feedback is incorporated into the HTML. (lincolnthree, 23:09:07) * Then it's time to implement on the live site. (lincolnthree, 23:09:17) * JBDS Forge 1 (gastaldi, 23:10:41) * Roadmap (gastaldi, 23:19:46) * LINK: https://developer.jboss.org/wiki/GSOC15Ideas#jive_content_id_Docker_Addon_for_JBoss_Forge (gastaldi, 23:25:23) -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150303/ea7fbc25/attachment.html From ivan.st.ivanov at gmail.com Wed Mar 4 16:47:10 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Wed, 4 Mar 2015 23:47:10 +0200 Subject: [forge-dev] Feedback on Documenting how to create and test a command that creates Java code Message-ID: Hi everybody, I went a few times through the tutorial on writing Java source Forge commands. Great effort! It was about time we have things like this (which is more a bad feedback for me, as I wanted to write something like this for quite a long time, but I haven't yet done it ;)). So, here is some things that I think can be improved: - Shouldn't the FAQ and the tutorial be separate documents? - Where did the UML diagram of the commands type structure go? - According to the title and to the introductory paragraphs of the tutorial section, a reader would feel that this is a generic paper about writing Forge commands in their own addon (something like in the Developing Forge section in the HoL). However, it is more about extending existing [core] addons with new commands. So maybe this could be stated more explicitly in the title? - The Metada.name method gets a string which is by convention something like ": ". Maybe it could be explained how would this translate on the command line and in the IDE, what are the common command groups and what is the convention for the command names - I personally need a better explanation about the difference between @AddonDeployments and ShrinkWrap.addAsAddonDependenies - It would be clearer if the UITestHarness and ShellTest classes and their purpose should be introduced right before the test methods that they are used in (checkCommandMetadata and checkCommandShell respectively) and not in the beginning of the section. Thus the reader does not lose the context around those test helper classes at the point they are used for the first time - In the beginning of the Let's add some business code section you refresh the readers about our goal (i.e. to create a constraint class), but not about the Forge command that we wrote before the test section. It may be a good idea to remind the reader about that as well, so that she does not have to scroll up to find what she did so far - It would be a good idea to have a few sentences about what is a facet before it is introduced for the first time in testCreateNewPayload method - There are some typos I suppose that you can turn reviewing on and I can do myself some of the most obvious fixes (like the typos for example), which you can review afterwards? Cheers, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150304/b103421d/attachment.html From antonio.mailing at gmail.com Thu Mar 5 07:26:43 2015 From: antonio.mailing at gmail.com (Antonio Goncalves) Date: Thu, 5 Mar 2015 13:26:43 +0100 Subject: [forge-dev] Feedback on Documenting how to create and test a command that creates Java code In-Reply-To: References: Message-ID: 2015-03-04 22:47 GMT+01:00 Ivan St. Ivanov : > Hi everybody, > > I went a few times through the tutorial on writing Java source Forge > commands. Great effort! It was about time we have things like this (which > is more a bad feedback for me, as I wanted to write something like this for > quite a long time, but I haven't yet done it ;)). > > So, here is some things that I think can be improved: > > - Shouldn't the FAQ and the tutorial be separate documents? > Yes, that's the idea > - Where did the UML diagram of the commands type structure go? > It's here https://issues.jboss.org/browse/FORGE-2109 I took it off because it's not what we have at the moment. I've started some refactoring so we would end up with a cleaner class hierarchy. > - According to the title and to the introductory paragraphs of the > tutorial section, a reader would feel that this is a generic paper about > writing Forge commands in their own addon (something like in the Developing > Forge section in the HoL). However, it is more about extending existing > [core] addons with new commands. So maybe this could be stated more > explicitly in the title? > Good point > - The Metada.name method gets a string which is by convention something > like ": ". Maybe it could be explained how > would this translate on the command line and in the IDE, what are the > common command groups and what is the convention for the command names > Feel free to explain it, I didn't know there was such a structure, I thought it was just free text (I don't use IDEs, just CLI ;o) > - I personally need a better explanation about the difference between > @AddonDeployments and ShrinkWrap.addAsAddonDependenies > Yes, I asked a few question to Lincoln and George. Their answer were ok, but I would like to have a deeper explanation. > - It would be clearer if the UITestHarness and ShellTest classes and their > purpose should be introduced right before the test methods that they are > used in (checkCommandMetadata and checkCommandShell respectively) and not > in the beginning of the section. Thus the reader does not lose the context > around those test helper classes at the point they are used for the first > time > Hum... I don't get it, feel free to update the doc - In the beginning of the Let's add some business code section you refresh > the readers about our goal (i.e. to create a constraint class), but not > about the Forge command that we wrote before the test section. It may be a > good idea to remind the reader about that as well, so that she does not > have to scroll up to find what she did so far > Done > - It would be a good idea to have a few sentences about what is a facet > before it is introduced for the first time in testCreateNewPayload method > I don't know much about it, so if you have some knowledge, feel free to change it. > - There are some typos > > I suppose that you can turn reviewing on and I can do myself some of the > most obvious fixes (like the typos for example), which you can review > afterwards? > I've added you write access to the doc. Feel free to change/comment/correct it Thanks Ivan for your feedback Antonio > > Cheers, > Ivan > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Antonio Goncalves Software architect and Java Champion Web site | Twitter | LinkedIn | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150305/a2c6cd29/attachment.html From ivan.st.ivanov at gmail.com Thu Mar 5 16:19:07 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Thu, 5 Mar 2015 23:19:07 +0200 Subject: [forge-dev] Feedback on Documenting how to create and test a command that creates Java code In-Reply-To: References: Message-ID: Thanks, Antonio! I'll take some time during the weekend to fix the low hanging fruit :) On Thu, Mar 5, 2015 at 2:26 PM, Antonio Goncalves wrote: > > > 2015-03-04 22:47 GMT+01:00 Ivan St. Ivanov : > >> Hi everybody, >> >> I went a few times through the tutorial on writing Java source Forge >> commands. Great effort! It was about time we have things like this (which >> is more a bad feedback for me, as I wanted to write something like this for >> quite a long time, but I haven't yet done it ;)). >> >> So, here is some things that I think can be improved: >> >> - Shouldn't the FAQ and the tutorial be separate documents? >> > > Yes, that's the idea > > > >> - Where did the UML diagram of the commands type structure go? >> > > It's here https://issues.jboss.org/browse/FORGE-2109 > I took it off because it's not what we have at the moment. I've started > some refactoring so we would end up with a cleaner class hierarchy. > > >> - According to the title and to the introductory paragraphs of the >> tutorial section, a reader would feel that this is a generic paper about >> writing Forge commands in their own addon (something like in the Developing >> Forge section in the HoL). However, it is more about extending existing >> [core] addons with new commands. So maybe this could be stated more >> explicitly in the title? >> > > Good point > > > >> - The Metada.name method gets a string which is by convention something >> like ": ". Maybe it could be explained how >> would this translate on the command line and in the IDE, what are the >> common command groups and what is the convention for the command names >> > > Feel free to explain it, I didn't know there was such a structure, I > thought it was just free text (I don't use IDEs, just CLI ;o) > > > >> - I personally need a better explanation about the difference between >> @AddonDeployments and ShrinkWrap.addAsAddonDependenies >> > > Yes, I asked a few question to Lincoln and George. Their answer were ok, > but I would like to have a deeper explanation. > > > >> - It would be clearer if the UITestHarness and ShellTest classes and >> their purpose should be introduced right before the test methods that they >> are used in (checkCommandMetadata and checkCommandShell respectively) and >> not in the beginning of the section. Thus the reader does not lose the >> context around those test helper classes at the point they are used for the >> first time >> > > Hum... I don't get it, feel free to update the doc > > > - In the beginning of the Let's add some business code section you refresh >> the readers about our goal (i.e. to create a constraint class), but not >> about the Forge command that we wrote before the test section. It may be a >> good idea to remind the reader about that as well, so that she does not >> have to scroll up to find what she did so far >> > > Done > > > >> - It would be a good idea to have a few sentences about what is a facet >> before it is introduced for the first time in testCreateNewPayload method >> > > I don't know much about it, so if you have some knowledge, feel free to > change it. > > >> - There are some typos >> >> I suppose that you can turn reviewing on and I can do myself some of the >> most obvious fixes (like the typos for example), which you can review >> afterwards? >> > > > I've added you write access to the doc. Feel free to > change/comment/correct it > > Thanks Ivan for your feedback > > Antonio > > >> >> Cheers, >> Ivan >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > > > > -- > Antonio Goncalves > Software architect and Java Champion > > Web site | Twitter > | LinkedIn > | Paris JUG > | Devoxx France > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150305/7673b03c/attachment-0001.html From antonio.mailing at gmail.com Sat Mar 7 09:29:39 2015 From: antonio.mailing at gmail.com (Antonio Goncalves) Date: Sat, 7 Mar 2015 15:29:39 +0100 Subject: [forge-dev] Feedback on Documenting how to create and test a command that creates Java code In-Reply-To: References: Message-ID: BTW, I've just added a second tutorial. Based on the first one (generated a single Java EE class) but adding some extra parameters (not just named and targetPackage). Antonio 2015-03-05 22:19 GMT+01:00 Ivan St. Ivanov : > Thanks, Antonio! I'll take some time during the weekend to fix the low > hanging fruit :) > > On Thu, Mar 5, 2015 at 2:26 PM, Antonio Goncalves < > antonio.mailing at gmail.com> wrote: > >> >> >> 2015-03-04 22:47 GMT+01:00 Ivan St. Ivanov : >> >>> Hi everybody, >>> >>> I went a few times through the tutorial on writing Java source Forge >>> commands. Great effort! It was about time we have things like this (which >>> is more a bad feedback for me, as I wanted to write something like this for >>> quite a long time, but I haven't yet done it ;)). >>> >>> So, here is some things that I think can be improved: >>> >>> - Shouldn't the FAQ and the tutorial be separate documents? >>> >> >> Yes, that's the idea >> >> >> >>> - Where did the UML diagram of the commands type structure go? >>> >> >> It's here https://issues.jboss.org/browse/FORGE-2109 >> I took it off because it's not what we have at the moment. I've started >> some refactoring so we would end up with a cleaner class hierarchy. >> >> >>> - According to the title and to the introductory paragraphs of the >>> tutorial section, a reader would feel that this is a generic paper about >>> writing Forge commands in their own addon (something like in the Developing >>> Forge section in the HoL). However, it is more about extending existing >>> [core] addons with new commands. So maybe this could be stated more >>> explicitly in the title? >>> >> >> Good point >> >> >> >>> - The Metada.name method gets a string which is by convention something >>> like ": ". Maybe it could be explained how >>> would this translate on the command line and in the IDE, what are the >>> common command groups and what is the convention for the command names >>> >> >> Feel free to explain it, I didn't know there was such a structure, I >> thought it was just free text (I don't use IDEs, just CLI ;o) >> >> >> >>> - I personally need a better explanation about the difference between >>> @AddonDeployments and ShrinkWrap.addAsAddonDependenies >>> >> >> Yes, I asked a few question to Lincoln and George. Their answer were ok, >> but I would like to have a deeper explanation. >> >> >> >>> - It would be clearer if the UITestHarness and ShellTest classes and >>> their purpose should be introduced right before the test methods that they >>> are used in (checkCommandMetadata and checkCommandShell respectively) and >>> not in the beginning of the section. Thus the reader does not lose the >>> context around those test helper classes at the point they are used for the >>> first time >>> >> >> Hum... I don't get it, feel free to update the doc >> >> >> - In the beginning of the Let's add some business code section you >>> refresh the readers about our goal (i.e. to create a constraint class), but >>> not about the Forge command that we wrote before the test section. It may >>> be a good idea to remind the reader about that as well, so that she does >>> not have to scroll up to find what she did so far >>> >> >> Done >> >> >> >>> - It would be a good idea to have a few sentences about what is a facet >>> before it is introduced for the first time in testCreateNewPayload method >>> >> >> I don't know much about it, so if you have some knowledge, feel free to >> change it. >> >> >>> - There are some typos >>> >>> I suppose that you can turn reviewing on and I can do myself some of the >>> most obvious fixes (like the typos for example), which you can review >>> afterwards? >>> >> >> >> I've added you write access to the doc. Feel free to >> change/comment/correct it >> >> Thanks Ivan for your feedback >> >> Antonio >> >> >>> >>> Cheers, >>> Ivan >>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >>> >> >> >> >> -- >> Antonio Goncalves >> Software architect and Java Champion >> >> Web site | Twitter >> | LinkedIn >> | Paris JUG >> | Devoxx France >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Antonio Goncalves Software architect and Java Champion Web site | Twitter | LinkedIn | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150307/6f5fb66d/attachment.html From ivan.st.ivanov at gmail.com Sun Mar 8 10:14:56 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Sun, 8 Mar 2015 16:14:56 +0200 Subject: [forge-dev] Feedback on Documenting how to create and test a command that creates Java code In-Reply-To: References: Message-ID: Hi Antonio, I've incorporated some changes in the following areas: - Fixed typos - Provided some more explanation on how the command name translates in the shell and in the IDEs - Gradually introduce the command test APIs About the other points from my feedback, I'm afraid I cannot explain much the Addon deployment stuff and detailed descriptions of facets may not be really appropriate for this tutorial. Will look at the second tutorial tonight or in the course of the next few days. Cheers, Ivan On Sat, Mar 7, 2015 at 4:29 PM, Antonio Goncalves wrote: > BTW, I've just added a second tutorial. Based on the first one (generated > a single Java EE class) but adding some extra parameters (not just named > and targetPackage). > > Antonio > > 2015-03-05 22:19 GMT+01:00 Ivan St. Ivanov : > >> Thanks, Antonio! I'll take some time during the weekend to fix the low >> hanging fruit :) >> >> On Thu, Mar 5, 2015 at 2:26 PM, Antonio Goncalves < >> antonio.mailing at gmail.com> wrote: >> >>> >>> >>> 2015-03-04 22:47 GMT+01:00 Ivan St. Ivanov : >>> >>>> Hi everybody, >>>> >>>> I went a few times through the tutorial on writing Java source Forge >>>> commands. Great effort! It was about time we have things like this (which >>>> is more a bad feedback for me, as I wanted to write something like this for >>>> quite a long time, but I haven't yet done it ;)). >>>> >>>> So, here is some things that I think can be improved: >>>> >>>> - Shouldn't the FAQ and the tutorial be separate documents? >>>> >>> >>> Yes, that's the idea >>> >>> >>> >>>> - Where did the UML diagram of the commands type structure go? >>>> >>> >>> It's here https://issues.jboss.org/browse/FORGE-2109 >>> I took it off because it's not what we have at the moment. I've started >>> some refactoring so we would end up with a cleaner class hierarchy. >>> >>> >>>> - According to the title and to the introductory paragraphs of the >>>> tutorial section, a reader would feel that this is a generic paper about >>>> writing Forge commands in their own addon (something like in the Developing >>>> Forge section in the HoL). However, it is more about extending existing >>>> [core] addons with new commands. So maybe this could be stated more >>>> explicitly in the title? >>>> >>> >>> Good point >>> >>> >>> >>>> - The Metada.name method gets a string which is by convention something >>>> like ": ". Maybe it could be explained how >>>> would this translate on the command line and in the IDE, what are the >>>> common command groups and what is the convention for the command names >>>> >>> >>> Feel free to explain it, I didn't know there was such a structure, I >>> thought it was just free text (I don't use IDEs, just CLI ;o) >>> >>> >>> >>>> - I personally need a better explanation about the difference between >>>> @AddonDeployments and ShrinkWrap.addAsAddonDependenies >>>> >>> >>> Yes, I asked a few question to Lincoln and George. Their answer were ok, >>> but I would like to have a deeper explanation. >>> >>> >>> >>>> - It would be clearer if the UITestHarness and ShellTest classes and >>>> their purpose should be introduced right before the test methods that they >>>> are used in (checkCommandMetadata and checkCommandShell respectively) and >>>> not in the beginning of the section. Thus the reader does not lose the >>>> context around those test helper classes at the point they are used for the >>>> first time >>>> >>> >>> Hum... I don't get it, feel free to update the doc >>> >>> >>> - In the beginning of the Let's add some business code section you >>>> refresh the readers about our goal (i.e. to create a constraint class), but >>>> not about the Forge command that we wrote before the test section. It may >>>> be a good idea to remind the reader about that as well, so that she does >>>> not have to scroll up to find what she did so far >>>> >>> >>> Done >>> >>> >>> >>>> - It would be a good idea to have a few sentences about what is a facet >>>> before it is introduced for the first time in testCreateNewPayload method >>>> >>> >>> I don't know much about it, so if you have some knowledge, feel free to >>> change it. >>> >>> >>>> - There are some typos >>>> >>>> I suppose that you can turn reviewing on and I can do myself some of >>>> the most obvious fixes (like the typos for example), which you can review >>>> afterwards? >>>> >>> >>> >>> I've added you write access to the doc. Feel free to >>> change/comment/correct it >>> >>> Thanks Ivan for your feedback >>> >>> Antonio >>> >>> >>>> >>>> Cheers, >>>> Ivan >>>> >>>> _______________________________________________ >>>> forge-dev mailing list >>>> forge-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/forge-dev >>>> >>> >>> >>> >>> -- >>> Antonio Goncalves >>> Software architect and Java Champion >>> >>> Web site | Twitter >>> | LinkedIn >>> | Paris JUG >>> | Devoxx France >>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >>> >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > > > > -- > Antonio Goncalves > Software architect and Java Champion > > Web site | Twitter > | LinkedIn > | Paris JUG > | Devoxx France > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150308/8abd77f8/attachment-0001.html From lincolnbaxter at gmail.com Tue Mar 10 10:41:39 2015 From: lincolnbaxter at gmail.com (Lincoln Baxter, III) Date: Tue, 10 Mar 2015 10:41:39 -0400 Subject: [forge-dev] Forge Meeting Minutes - 2015-03-10 Message-ID: Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-10-14.03.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-10-14.03.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-10-14.03.log.html Meeting summary --------------- * Agenda (lincolnthree, 14:03:36) * Status Reports (lincolnthree, 14:06:56) * I've refactored the Furnace test harness to introduce the AddonArchive and @AddonDeployments features (lincolnthree, 14:07:19) * it's now possible to use @AddonDependencies to automatically add dependencies to the AddonArchive, without needing to duplicate the information in the @Deployment method itself (lincolnthree, 14:07:49) * You can also control import/export of the dependencies from the @AddonDependency or @AddonDeployment annotations. (lincolnthree, 14:08:07) * This was released in 2.15.0 and 2.15.1 (there was a bug) (lincolnthree, 14:08:30) * I also spent a good amount of time reviewing latest changes to the website, and I'm going to meet with the designer this week to discuss remaining issues (lincolnthree, 14:09:00) * Forge 2.15.1.Final will be released today (gastaldi, 14:09:39) * I also implemented an AddonLoadingStrategy policy with gastaldi that allows you to control what versions of addons may or may not be loaded by Furnace (lincolnthree, 14:10:01) * that's all from me (lincolnthree, 14:10:07) * Issues related to the Furnace container should now go into https://issues.jboss.org/browse/FURNACE (gastaldi, 14:10:56) * I'll move the open issues associated with Furnace over there (gastaldi, 14:11:14) * Furnace has now a separate JIRA project because it has it's own release cycle (gastaldi, 14:11:48) * Finished writing Tutorial on creating a new Java EE Command (needs to be reviewed) (agoncal, 14:13:42) * Started working on the second Tutorial about creating a new Java EE command that updates code (agoncal, 14:14:19) * Website Status (lincolnthree, 14:27:25) * I did the second review with the designer and found a lot of new issues with the site, so? sent it back for more fixes. Going to meet with him later this week to review and make sure it all gets fixed. (lincolnthree, 14:27:51) * Forge 2.15.1.Final is released! (lincolnthree, 14:40:07) * LINK: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12311820&version=12326733 (gastaldi, 14:40:23) * https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12311820&version=12326733 (lincolnthree, 14:40:38) -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150310/0ea01750/attachment.html From ivan.st.ivanov at gmail.com Tue Mar 10 10:58:05 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Tue, 10 Mar 2015 16:58:05 +0200 Subject: [forge-dev] Forge Meeting Minutes - 2015-03-10 In-Reply-To: References: Message-ID: Damn daylight savings time (starting differently in Europe and US) :) Thanks Lincoln for simplifying the addon dependency stuff in the test cases! Are there any examples of the new usage? :) On Tue, Mar 10, 2015 at 4:41 PM, Lincoln Baxter, III < lincolnbaxter at gmail.com> wrote: > Minutes: > http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-10-14.03.html > > Minutes (text): > http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-10-14.03.txt > > Log: > http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-10-14.03.log.html > > > > Meeting summary > --------------- > * Agenda (lincolnthree, 14:03:36) > > * Status Reports (lincolnthree, 14:06:56) > * I've refactored the Furnace test harness to introduce the > AddonArchive and @AddonDeployments features (lincolnthree, > 14:07:19) > * it's now possible to use @AddonDependencies to automatically add > dependencies to the AddonArchive, without needing to duplicate the > information in the @Deployment method itself (lincolnthree, > 14:07:49) > * You can also control import/export of the dependencies from the > @AddonDependency or @AddonDeployment annotations. (lincolnthree, > 14:08:07) > * This was released in 2.15.0 and 2.15.1 (there was a bug) > (lincolnthree, 14:08:30) > * I also spent a good amount of time reviewing latest changes to the > website, and I'm going to meet with the designer this week to > discuss remaining issues (lincolnthree, 14:09:00) > * Forge 2.15.1.Final will be released today (gastaldi, 14:09:39) > * I also implemented an AddonLoadingStrategy policy with gastaldi that > allows you to control what versions of addons may or may not be > loaded by Furnace (lincolnthree, 14:10:01) > * that's all from me (lincolnthree, 14:10:07) > * Issues related to the Furnace container should now go into > https://issues.jboss.org/browse/FURNACE (gastaldi, 14:10:56) > * I'll move the open issues associated with Furnace over there > (gastaldi, 14:11:14) > * Furnace has now a separate JIRA project because it has it's own > release cycle (gastaldi, 14:11:48) > * Finished writing Tutorial on creating a new Java EE Command (needs > to be reviewed) (agoncal, 14:13:42) > * Started working on the second Tutorial about creating a new Java EE > command that updates code (agoncal, 14:14:19) > > * Website Status (lincolnthree, 14:27:25) > * I did the second review with the designer and found a lot of new > issues with the site, so? sent it back for more fixes. Going to meet > with him later this week to review and make sure it all gets fixed. > (lincolnthree, 14:27:51) > * Forge 2.15.1.Final is released! (lincolnthree, 14:40:07) > * LINK: > https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12311820&version=12326733 > (gastaldi, 14:40:23) > * > https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12311820&version=12326733 > (lincolnthree, 14:40:38) > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150310/ac4b01ff/attachment.html From antonio.mailing at gmail.com Wed Mar 11 11:48:28 2015 From: antonio.mailing at gmail.com (Antonio Goncalves) Date: Wed, 11 Mar 2015 16:48:28 +0100 Subject: [forge-dev] Forge Meeting Minutes - 2015-03-10 In-Reply-To: References: Message-ID: I'll refactor the tests that I've used in the Tutorial... and update the Tutorial (of course) : https://issues.jboss.org/browse/FORGE-2275 Antonio 2015-03-10 15:58 GMT+01:00 Ivan St. Ivanov : > Damn daylight savings time (starting differently in Europe and US) :) > > Thanks Lincoln for simplifying the addon dependency stuff in the test > cases! Are there any examples of the new usage? :) > > On Tue, Mar 10, 2015 at 4:41 PM, Lincoln Baxter, III < > lincolnbaxter at gmail.com> wrote: > >> Minutes: >> http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-10-14.03.html >> >> Minutes (text): >> http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-10-14.03.txt >> >> Log: >> http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-03-10-14.03.log.html >> >> >> >> Meeting summary >> --------------- >> * Agenda (lincolnthree, 14:03:36) >> >> * Status Reports (lincolnthree, 14:06:56) >> * I've refactored the Furnace test harness to introduce the >> AddonArchive and @AddonDeployments features (lincolnthree, >> 14:07:19) >> * it's now possible to use @AddonDependencies to automatically add >> dependencies to the AddonArchive, without needing to duplicate the >> information in the @Deployment method itself (lincolnthree, >> 14:07:49) >> * You can also control import/export of the dependencies from the >> @AddonDependency or @AddonDeployment annotations. (lincolnthree, >> 14:08:07) >> * This was released in 2.15.0 and 2.15.1 (there was a bug) >> (lincolnthree, 14:08:30) >> * I also spent a good amount of time reviewing latest changes to the >> website, and I'm going to meet with the designer this week to >> discuss remaining issues (lincolnthree, 14:09:00) >> * Forge 2.15.1.Final will be released today (gastaldi, 14:09:39) >> * I also implemented an AddonLoadingStrategy policy with gastaldi that >> allows you to control what versions of addons may or may not be >> loaded by Furnace (lincolnthree, 14:10:01) >> * that's all from me (lincolnthree, 14:10:07) >> * Issues related to the Furnace container should now go into >> https://issues.jboss.org/browse/FURNACE (gastaldi, 14:10:56) >> * I'll move the open issues associated with Furnace over there >> (gastaldi, 14:11:14) >> * Furnace has now a separate JIRA project because it has it's own >> release cycle (gastaldi, 14:11:48) >> * Finished writing Tutorial on creating a new Java EE Command (needs >> to be reviewed) (agoncal, 14:13:42) >> * Started working on the second Tutorial about creating a new Java EE >> command that updates code (agoncal, 14:14:19) >> >> * Website Status (lincolnthree, 14:27:25) >> * I did the second review with the designer and found a lot of new >> issues with the site, so? sent it back for more fixes. Going to meet >> with him later this week to review and make sure it all gets fixed. >> (lincolnthree, 14:27:51) >> * Forge 2.15.1.Final is released! (lincolnthree, 14:40:07) >> * LINK: >> https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12311820&version=12326733 >> (gastaldi, 14:40:23) >> * >> https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12311820&version=12326733 >> (lincolnthree, 14:40:38) >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Antonio Goncalves Software architect and Java Champion Web site | Twitter | LinkedIn | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150311/c4f82f2c/attachment-0001.html From antonio.mailing at gmail.com Fri Mar 13 17:07:55 2015 From: antonio.mailing at gmail.com (Antonio Goncalves) Date: Fri, 13 Mar 2015 22:07:55 +0100 Subject: [forge-dev] Forge Meeting Minutes - 2015-03-10 Message-ID: Hi all, I am having a look at some visitor code, and then, I realized that I don't understand the difference between a JavaType and @Override public void visit(VisitContext context, JavaResource resource) { try { JavaType javaType = resource.getJavaType(); if (javaType.isClass() && !javaType.hasAnnotation(Entity.class) javaSource.hasAnnotation(MappedSuperclass.class)) { classes.add(resource); } } catch (FileNotFoundException e) { // ignore } } -- Antonio Goncalves Software architect and Java Champion Web site | Twitter | LinkedIn | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150313/a0f07164/attachment.html From antonio.mailing at gmail.com Fri Mar 13 17:18:35 2015 From: antonio.mailing at gmail.com (Antonio Goncalves) Date: Fri, 13 Mar 2015 22:18:35 +0100 Subject: [forge-dev] JavaType vs JavaSource Message-ID: Hi all, I am having a look at some code and realize that I don't understand the subtle difference between JavaType and JavaSource in certain cases. In some visitor code (see below), I see : JavaType javaType = resource.getJavaType(); And other times I see : JavaSource javaSource = javaResource.getJavaType(); So I look at the code. JavaSource extends from JavaType, adds one method, and then they both implement similar interfaces (JavaDocCapable vs JavaDocCapableSource). So, in the following example, why use JavaSource instead of JavaType ? Thanks Antonio @Override public void visit(VisitContext context, JavaResource resource) { try { *JavaType javaType = resource.getJavaType();* if (javaType.isClass() && !javaType.hasAnnotation(Entity.class) javaSource.hasAnnotation(MappedSuperclass.class)) { classes.add(resource); } } catch (FileNotFoundException e) { // ignore } } -- Antonio Goncalves Software architect and Java Champion Web site | Twitter | LinkedIn | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150313/c7b3a8e8/attachment.html From antonio.mailing at gmail.com Fri Mar 13 17:59:43 2015 From: antonio.mailing at gmail.com (Antonio Goncalves) Date: Fri, 13 Mar 2015 22:59:43 +0100 Subject: [forge-dev] Add vs New Message-ID: Hi all, I'm a bit particular on wording because I think that the right word makes things easier for the new comer. I'm implementing a new UI command to add an injection point to a class. So, the name of the command would be cdi-add-injection-point. But then I started to have a look at the other xxx- *add*-yyy commands : addon-add-dependency project-add-dependencies project-add-managed-dependencies project-add-repository java-add-annotation constraint-add They all add something, into something already existing. If we take this definition for granted, shouldn't the following commands be renamed *add* instead of *new* : jpa-new-named-query cdi-new-conversation java-new-enum-const java-new-field java-new-method jpa-new-field -- Antonio Goncalves Software architect and Java Champion Web site | Twitter | LinkedIn | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150313/626cb3ba/attachment.html From ggastald at redhat.com Fri Mar 13 18:10:53 2015 From: ggastald at redhat.com (George Gastaldi) Date: Fri, 13 Mar 2015 18:10:53 -0400 (EDT) Subject: [forge-dev] Add vs New In-Reply-To: References: Message-ID: That makes sense, however renaming these commands will break existing scripts. This should be something to be considered for Forge 3.x > Em 13/03/2015, ?s 19:00, Antonio Goncalves escreveu: > > Hi all, > > I'm a bit particular on wording because I think that the right word makes things easier for the new comer. I'm implementing a new UI command to add an injection point to a class. So, the name of the command would be cdi-add-injection-point. But then I started to have a look at the other xxx-add-yyy commands : > > addon-add-dependency > project-add-dependencies > project-add-managed-dependencies > project-add-repository > java-add-annotation > constraint-add > > They all add something, into something already existing. If we take this definition for granted, shouldn't the following commands be renamed add instead of new : > > jpa-new-named-query > cdi-new-conversation > java-new-enum-const > java-new-field > java-new-method > jpa-new-field > > > > -- > Antonio Goncalves > Software architect and Java Champion > > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150313/8e0dee6f/attachment.html From ggastald at redhat.com Fri Mar 13 18:16:14 2015 From: ggastald at redhat.com (George Gastaldi) Date: Fri, 13 Mar 2015 18:16:14 -0400 (EDT) Subject: [forge-dev] JavaType vs JavaSource In-Reply-To: References: Message-ID: <8037A7B1-BCEF-430A-88C8-A232A7CC7094@redhat.com> IMHO, there is a minor difference that may explain it. JavaType should be used when the object might be a compiled java type vs when you have the source code of a Java type (JavaSource). In practice they don't differ much but afaik this was the main difference. PS: Roaster does not support parsing of compiled java types yet, but the model is ready for this feature when it becomes available. > Em 13/03/2015, ?s 18:19, Antonio Goncalves escreveu: > > Hi all, > > I am having a look at some code and realize that I don't understand the subtle difference between JavaType and JavaSource in certain cases. In some visitor code (see below), I see : > > JavaType javaType = resource.getJavaType(); > > And other times I see : > > JavaSource javaSource = javaResource.getJavaType(); > > So I look at the code. JavaSource extends from JavaType, adds one method, and then they both implement similar interfaces (JavaDocCapable vs JavaDocCapableSource). > > So, in the following example, why use JavaSource instead of JavaType ? > > Thanks > Antonio > > @Override > public void visit(VisitContext context, JavaResource resource) > { > try > { > JavaType javaType = resource.getJavaType(); > if (javaType.isClass() && !javaType.hasAnnotation(Entity.class) javaSource.hasAnnotation(MappedSuperclass.class)) > { > classes.add(resource); > } > } > catch (FileNotFoundException e) > { > // ignore > } > } > > > -- > Antonio Goncalves > Software architect and Java Champion > > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150313/ec4d51d5/attachment-0001.html From antonio.mailing at gmail.com Sat Mar 14 05:37:40 2015 From: antonio.mailing at gmail.com (Antonio Goncalves) Date: Sat, 14 Mar 2015 10:37:40 +0100 Subject: [forge-dev] Add vs New In-Reply-To: References: Message-ID: Yes. I've created a JIRA for Forge 3.x : https://issues.jboss.org/browse/FORGE-2277 Antonio 2015-03-13 23:10 GMT+01:00 George Gastaldi : > That makes sense, however renaming these commands will break existing > scripts. This should be something to be considered for Forge 3.x > > > > Em 13/03/2015, ?s 19:00, Antonio Goncalves > escreveu: > > Hi all, > > I'm a bit particular on wording because I think that the right word makes > things easier for the new comer. I'm implementing a new UI command to add > an injection point to a class. So, the name of the command would be > cdi-add-injection-point. But then I started to have a look at the other > xxx-*add*-yyy commands : > > addon-add-dependency > project-add-dependencies > project-add-managed-dependencies > project-add-repository > java-add-annotation > constraint-add > > They all add something, into something already existing. If we take this > definition for granted, shouldn't the following commands be renamed *add* > instead of *new* : > > jpa-new-named-query > cdi-new-conversation > java-new-enum-const > java-new-field > java-new-method > jpa-new-field > > > > -- > Antonio Goncalves > Software architect and Java Champion > > Web site | Twitter > | LinkedIn > | Paris JUG > | Devoxx France > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Antonio Goncalves Software architect and Java Champion Web site | Twitter | LinkedIn | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150314/e6a9f35c/attachment.html From antonio.mailing at gmail.com Sat Mar 14 05:41:13 2015 From: antonio.mailing at gmail.com (Antonio Goncalves) Date: Sat, 14 Mar 2015 10:41:13 +0100 Subject: [forge-dev] JavaType vs JavaSource In-Reply-To: <8037A7B1-BCEF-430A-88C8-A232A7CC7094@redhat.com> References: <8037A7B1-BCEF-430A-88C8-A232A7CC7094@redhat.com> Message-ID: What do you mean by "compiled java type" ? Something like java.lang.String because it's in the rt.jar and you don't have the sources ? Because most of the visitors "visit our code" (i.e. the code in the project we are generating to with Forge). So that would mean that most of the visistors should then use JavaSource ? And in terms of performance, is there a difference ? Is it "faster" to parse source code rather then byte code ? Antonio 2015-03-13 23:16 GMT+01:00 George Gastaldi : > IMHO, there is a minor difference that may explain it. JavaType should be > used when the object might be a compiled java type vs when you have the > source code of a Java type (JavaSource). In practice they don't differ much > but afaik this was the main difference. > > PS: Roaster does not support parsing of compiled java types yet, but the > model is ready for this feature when it becomes available. > > > > Em 13/03/2015, ?s 18:19, Antonio Goncalves > escreveu: > > Hi all, > > I am having a look at some code and realize that I don't understand the > subtle difference between JavaType and JavaSource in certain cases. In > some visitor code (see below), I see : > > JavaType javaType = resource.getJavaType(); > > And other times I see : > > JavaSource javaSource = javaResource.getJavaType(); > > So I look at the code. JavaSource extends from JavaType, adds one method, > and then they both implement similar interfaces (JavaDocCapable vs > JavaDocCapableSource). > > So, in the following example, why use JavaSource instead of JavaType ? > > Thanks > Antonio > > @Override > public void visit(VisitContext context, JavaResource resource) > { > try > { > *JavaType javaType = resource.getJavaType();* > if (javaType.isClass() && > !javaType.hasAnnotation(Entity.class) > javaSource.hasAnnotation(MappedSuperclass.class)) > { > classes.add(resource); > } > } > catch (FileNotFoundException e) > { > // ignore > } > } > > > -- > Antonio Goncalves > Software architect and Java Champion > > Web site | Twitter > | LinkedIn > | Paris JUG > | Devoxx France > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Antonio Goncalves Software architect and Java Champion Web site | Twitter | LinkedIn | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150314/28a11234/attachment.html From manderse at redhat.com Sat Mar 14 07:21:43 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Sat, 14 Mar 2015 04:21:43 -0700 Subject: [forge-dev] Add vs New In-Reply-To: References: Message-ID: <0AF4A667-62BF-41B9-BDFC-5E21DE6A07C2@redhat.com> On 13 Mar 2015, at 15:10, George Gastaldi wrote: > That makes sense, however renaming these commands will break existing > scripts. This should be something to be considered for Forge 3.x does forge 2 not have a notion of aliases or similar that could be used to create uniformity but still be backwards compatible ? /max > > >> Em 13/03/2015, ?s 19:00, Antonio Goncalves >> escreveu: >> >> Hi all, >> >> I'm a bit particular on wording because I think that the right word >> makes things easier for the new comer. I'm implementing a new UI >> command to add an injection point to a class. So, the name of the >> command would be cdi-add-injection-point. But then I started to have >> a look at the other xxx-add-yyy commands : >> >> addon-add-dependency >> project-add-dependencies >> project-add-managed-dependencies >> project-add-repository >> java-add-annotation >> constraint-add >> >> They all add something, into something already existing. If we take >> this definition for granted, shouldn't the following commands be >> renamed add instead of new : >> >> jpa-new-named-query >> cdi-new-conversation >> java-new-enum-const >> java-new-field >> java-new-method >> jpa-new-field >> >> >> >> -- >> Antonio Goncalves >> Software architect and Java Champion >> >> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev /max http://about.me/maxandersen From ggastald at redhat.com Sat Mar 14 10:18:40 2015 From: ggastald at redhat.com (George Gastaldi) Date: Sat, 14 Mar 2015 10:18:40 -0400 (EDT) Subject: [forge-dev] Add vs New In-Reply-To: <0AF4A667-62BF-41B9-BDFC-5E21DE6A07C2@redhat.com> References: <0AF4A667-62BF-41B9-BDFC-5E21DE6A07C2@redhat.com> Message-ID: I've been thinking about that yesterday and I think it's possible. Even though we have the 'alias' command in shell, that doesn't apply for GUI envs. It would be nice if we could define an alternative name (or alias) in the command itself. I'd prefer that only the new command name is shown when or the list of commands is invoked in the IDE, but making the old command name still work if typed directly. > Em 14/03/2015, ?s 08:21, Max Rydahl Andersen escreveu: > >> On 13 Mar 2015, at 15:10, George Gastaldi wrote: >> >> That makes sense, however renaming these commands will break existing >> scripts. This should be something to be considered for Forge 3.x > > does forge 2 not have a notion of aliases or similar that could be used > to create uniformity but still be backwards compatible ? > > /max > >> >> >>> Em 13/03/2015, ?s 19:00, Antonio Goncalves >>> escreveu: >>> >>> Hi all, >>> >>> I'm a bit particular on wording because I think that the right word >>> makes things easier for the new comer. I'm implementing a new UI >>> command to add an injection point to a class. So, the name of the >>> command would be cdi-add-injection-point. But then I started to have >>> a look at the other xxx-add-yyy commands : >>> >>> addon-add-dependency >>> project-add-dependencies >>> project-add-managed-dependencies >>> project-add-repository >>> java-add-annotation >>> constraint-add >>> >>> They all add something, into something already existing. If we take >>> this definition for granted, shouldn't the following commands be >>> renamed add instead of new : >>> >>> jpa-new-named-query >>> cdi-new-conversation >>> java-new-enum-const >>> java-new-field >>> java-new-method >>> jpa-new-field >>> >>> >>> >>> -- >>> Antonio Goncalves >>> Software architect and Java Champion >>> >>> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > /max > http://about.me/maxandersen > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev From ggastald at redhat.com Sat Mar 14 10:23:12 2015 From: ggastald at redhat.com (George Gastaldi) Date: Sat, 14 Mar 2015 10:23:12 -0400 (EDT) Subject: [forge-dev] JavaType vs JavaSource In-Reply-To: References: <8037A7B1-BCEF-430A-88C8-A232A7CC7094@redhat.com> Message-ID: Hi Antonio, By compiled java type I mean a class when you don't have the sources and therefore you can't modify its structure (like java.lang.String). I believe that most of the visitors could use JavaSource instead. As I beforementioned, Roaster still does not support this feature(parsing compiled classes), so I can't tell in terms of performance which one is faster. > Em 14/03/2015, ?s 06:41, Antonio Goncalves escreveu: > > What do you mean by "compiled java type" ? Something like java.lang.String because it's in the rt.jar and you don't have the sources ? Because most of the visitors "visit our code" (i.e. the code in the project we are generating to with Forge). So that would mean that most of the visistors should then use JavaSource ? > > And in terms of performance, is there a difference ? Is it "faster" to parse source code rather then byte code ? > > Antonio > > 2015-03-13 23:16 GMT+01:00 George Gastaldi : >> IMHO, there is a minor difference that may explain it. JavaType should be used when the object might be a compiled java type vs when you have the source code of a Java type (JavaSource). In practice they don't differ much but afaik this was the main difference. >> >> PS: Roaster does not support parsing of compiled java types yet, but the model is ready for this feature when it becomes available. >> >> >> >>> Em 13/03/2015, ?s 18:19, Antonio Goncalves escreveu: >>> >> >>> Hi all, >>> >>> I am having a look at some code and realize that I don't understand the subtle difference between JavaType and JavaSource in certain cases. In some visitor code (see below), I see : >>> >>> JavaType javaType = resource.getJavaType(); >>> >>> And other times I see : >>> >>> JavaSource javaSource = javaResource.getJavaType(); >>> >>> So I look at the code. JavaSource extends from JavaType, adds one method, and then they both implement similar interfaces (JavaDocCapable vs JavaDocCapableSource). >>> >>> So, in the following example, why use JavaSource instead of JavaType ? >>> >>> Thanks >>> Antonio >>> >>> @Override >>> public void visit(VisitContext context, JavaResource resource) >>> { >>> try >>> { >>> JavaType javaType = resource.getJavaType(); >>> if (javaType.isClass() && !javaType.hasAnnotation(Entity.class) javaSource.hasAnnotation(MappedSuperclass.class)) >>> { >>> classes.add(resource); >>> } >>> } >>> catch (FileNotFoundException e) >>> { >>> // ignore >>> } >>> } >>> >>> >>> -- >>> Antonio Goncalves >>> Software architect and Java Champion >>> >>> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > > -- > Antonio Goncalves > Software architect and Java Champion > > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150314/babca8a4/attachment-0001.html From vpereira at redhat.com Tue Mar 17 07:44:57 2015 From: vpereira at redhat.com (Vineet Reynolds Pereira) Date: Tue, 17 Mar 2015 07:44:57 -0400 (EDT) Subject: [forge-dev] Exception in IntelliJ plugin. In-Reply-To: <394562619.6544572.1426591818904.JavaMail.zimbra@redhat.com> Message-ID: <1269002528.6548022.1426592697981.JavaMail.zimbra@redhat.com> Has anyone else seen this ? I see these exceptions in the event log, and also in the list of fatal IDE errors. It does not seem to have broken anything since I can open the command dialog window (Ctrl+Alt+4) and also run commands. I'm using IDEA 14.0.3 and the Forge IntelliJ plugin 1.0.9.Final on Fedora 20 with Oracle Java 1.8.0_11. sun.awt.image.BufImgSurfaceData cannot be cast to sun.java2d.xr.XRSurfaceData java.lang.ClassCastException: sun.awt.image.BufImgSurfaceData cannot be cast to sun.java2d.xr.XRSurfaceData at sun.java2d.xr.XRPMBlitLoops.cacheToTmpSurface(XRPMBlitLoops.java:145) at sun.java2d.xr.XrSwToPMBlit.Blit(XRPMBlitLoops.java:353) at sun.java2d.pipe.DrawImage.blitSurfaceData(DrawImage.java:958) at sun.java2d.pipe.DrawImage.renderImageCopy(DrawImage.java:576) at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:67) at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:1013) at sun.java2d.pipe.ValidatePipe.copyImage(ValidatePipe.java:186) at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:3194) at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:3172) at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1542) at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1455) at javax.swing.RepaintManager.paint(RepaintManager.java:1252) at javax.swing.JComponent.paint(JComponent.java:1039) at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39) at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79) at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116) at java.awt.Container.paint(Container.java:1973) at java.awt.Window.paint(Window.java:3901) at com.intellij.openapi.ui.impl.DialogWrapperPeerImpl$MyDialog.paint(DialogWrapperPeerImpl.java:908) at javax.swing.RepaintManager$3.run(RepaintManager.java:822) at javax.swing.RepaintManager$3.run(RepaintManager.java:794) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:794) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:769) at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:718) at javax.swing.RepaintManager.access$1100(RepaintManager.java:62) at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1680) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) at java.awt.EventQueue.access$400(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:697) at java.awt.EventQueue$3.run(EventQueue.java:691) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) at com.intellij.ide.IdeEventQueue.e(IdeEventQueue.java:748) at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:577) at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:384) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:109) at java.awt.WaitDispatchSupport$2.run(WaitDispatchSupport.java:184) at java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:229) at java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:227) at java.security.AccessController.doPrivileged(Native Method) at java.awt.WaitDispatchSupport.enter(WaitDispatchSupport.java:227) at java.awt.Dialog.show(Dialog.java:1084) at com.intellij.openapi.ui.impl.DialogWrapperPeerImpl$MyDialog.show(DialogWrapperPeerImpl.java:779) at com.intellij.openapi.ui.impl.DialogWrapperPeerImpl.show(DialogWrapperPeerImpl.java:464) at com.intellij.openapi.ui.DialogWrapper.showAndGetOk(DialogWrapper.java:1569) at com.intellij.openapi.ui.DialogWrapper.show(DialogWrapper.java:1536) at org.jboss.forge.plugin.idea.ui.CommandListPopupBuilder.openWizard(CommandListPopupBuilder.java:195) at org.jboss.forge.plugin.idea.ui.CommandListPopupBuilder.access$300(CommandListPopupBuilder.java:39) at org.jboss.forge.plugin.idea.ui.CommandListPopupBuilder$3.run(CommandListPopupBuilder.java:158) at com.intellij.ui.popup.AbstractPopup$18.run(AbstractPopup.java:1343) at com.intellij.openapi.wm.impl.FocusManagerImpl.a(FocusManagerImpl.java:651) at com.intellij.openapi.wm.impl.FocusManagerImpl.g(FocusManagerImpl.java:632) at com.intellij.openapi.wm.impl.FocusManagerImpl.e(FocusManagerImpl.java:602) at com.intellij.openapi.wm.impl.FocusManagerImpl.access$200(FocusManagerImpl.java:60) at com.intellij.openapi.wm.impl.FocusManagerImpl$IdleRunnable.runEdt(FocusManagerImpl.java:108) at com.intellij.openapi.util.EdtRunnable$1.run(EdtRunnable.java:28) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) at java.awt.EventQueue.access$400(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:697) at java.awt.EventQueue$3.run(EventQueue.java:691) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) at com.intellij.ide.IdeEventQueue.e(IdeEventQueue.java:748) at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:577) at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:384) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)