From ivan.st.ivanov at gmail.com Fri Jul 3 08:36:33 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Fri, 3 Jul 2015 15:36:33 +0300 Subject: [forge-dev] Interesting behavior of CommandController (bug or feature ; )) Message-ID: Hi everybody, Believe it or not, but I resumed my work on the Servlet Security addon for Forge (https://issues.jboss.org/browse/FORGEPLUGINS-152) :) And I found something that I don't know whether is a bug or a feature. If my Command class implements the PrerequisiteCommandsProvider and if I try to use the CommandController in my integration test, then I have a problem. Here is a sample code: try (CommandController commandController = testHarness .createCommandController(SecuritySetupCommand.class, project.getRoot())) { commandController.initialize(); commandController.setValueFor("securityRealm", realm); commandController.setValueFor("authMethod", authenticationMethod); commandController.execute(); } This code fails at the setValueFor method simply because the UI was not initialized in the initialize method above it and there are no such inputs like securityRealm and authMethod. I did some debugging and found that if SecuritySetupCommand implements the PrerequisiteCommandsProvider interface, the commandController.initialize() method does not call PrerequisiteCommandsProvider#initializeUI method. Instead it triggeres PrerequisiteCommandTransformer.DelegateWizard#initializeUI. Which is empty and does nothing. And that's the reason why there are no securityRealm and authMethod controls. I guess that it is caused by some CDI "magic"? So I wonder is it a bug or a feature? Can I use CommandController to test commands that implement PrerequisiteCommandsProvider? Thanks, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150703/f7f9f713/attachment.html From ggastald at redhat.com Fri Jul 3 10:23:49 2015 From: ggastald at redhat.com (George Gastaldi) Date: Fri, 03 Jul 2015 11:23:49 -0300 Subject: [forge-dev] Interesting behavior of CommandController (bug or feature ; )) In-Reply-To: References: Message-ID: <55969AF5.7000808@redhat.com> Hi Ivan, Glad you decided to resume your work on the servlet security addon. When your command use a PreRequisiteCommandProvider, the initial step might not be your command in question, but the commands to be executed before that. That's why your setValueFor method might fail. What are the inputs returned in your test after you call initialize() (commandController.getInputs()) ? Best Regards, George Gastaldi On 07/03/2015 09:36 AM, Ivan St. Ivanov wrote: > Hi everybody, > > Believe it or not, but I resumed my work on the Servlet Security addon > for Forge (https://issues.jboss.org/browse/FORGEPLUGINS-152) :) > > And I found something that I don't know whether is a bug or a feature. > If my Command class implements the PrerequisiteCommandsProvider and if > I try to use the CommandController in my integration test, then I have > a problem. Here is a sample code: > > try (CommandController commandController = testHarness > .createCommandController(SecuritySetupCommand.class, project.getRoot())) > { > commandController.initialize(); > commandController.setValueFor("securityRealm", realm); > commandController.setValueFor("authMethod", > authenticationMethod); > commandController.execute(); > } > > This code fails at the setValueFor method simply because the UI was > not initialized in the initialize method above it and there are no > such inputs like securityRealm and authMethod. > > I did some debugging and found that if SecuritySetupCommand implements > the PrerequisiteCommandsProvider interface, the > commandController.initialize() method does not > call PrerequisiteCommandsProvider#initializeUI method. Instead it > triggeres PrerequisiteCommandTransformer.DelegateWizard#initializeUI. > Which is empty and does nothing. And that's the reason why there are > no securityRealm and authMethod controls. > > I guess that it is caused by some CDI "magic"? So I wonder is it a bug > or a feature? Can I use CommandController to test commands that > implement PrerequisiteCommandsProvider? > > Thanks, > Ivan > > > _______________________________________________ > 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/20150703/826f8045/attachment.html From ivan.st.ivanov at gmail.com Fri Jul 3 16:31:51 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Fri, 3 Jul 2015 23:31:51 +0300 Subject: [forge-dev] Interesting behavior of CommandController (bug or feature ; )) In-Reply-To: <55969AF5.7000808@redhat.com> References: <55969AF5.7000808@redhat.com> Message-ID: Hey George, Thanks for your answer! :) Well, maybe I am mismatching two concepts. So, my command that implements PrerequisiteCommandsProvider does this: @Override public NavigationResult getPrerequisiteCommands(UIContext context) { NavigationResultBuilder builder = NavigationResultBuilder.create(); builder.add(ServletSetupWizard.class); return builder.build(); } Then, just before I execute the command controller thing, I install the Servlet facet for the corresponding Servlet version. But most probably installing a facet does not disable the prerequisite command? Cheers, Ivan On Fri, Jul 3, 2015 at 5:23 PM, George Gastaldi wrote: > Hi Ivan, > > Glad you decided to resume your work on the servlet security addon. > > When your command use a PreRequisiteCommandProvider, the initial step > might not be your command in question, but the commands to be executed > before that. That's why your setValueFor method might fail. > > What are the inputs returned in your test after you call initialize() > (commandController.getInputs()) ? > > Best Regards, > > George Gastaldi > > > On 07/03/2015 09:36 AM, Ivan St. Ivanov wrote: > > Hi everybody, > > Believe it or not, but I resumed my work on the Servlet Security addon > for Forge (https://issues.jboss.org/browse/FORGEPLUGINS-152) :) > > And I found something that I don't know whether is a bug or a feature. > If my Command class implements the PrerequisiteCommandsProvider and if I > try to use the CommandController in my integration test, then I have a > problem. Here is a sample code: > > try (CommandController commandController = testHarness > .createCommandController(SecuritySetupCommand.class, > project.getRoot())) > { > commandController.initialize(); > commandController.setValueFor("securityRealm", realm); > commandController.setValueFor("authMethod", authenticationMethod); > commandController.execute(); > } > > This code fails at the setValueFor method simply because the UI was not > initialized in the initialize method above it and there are no such inputs > like securityRealm and authMethod. > > I did some debugging and found that if SecuritySetupCommand implements > the PrerequisiteCommandsProvider interface, the > commandController.initialize() method does not > call PrerequisiteCommandsProvider#initializeUI method. Instead it > triggeres PrerequisiteCommandTransformer.DelegateWizard#initializeUI. Which > is empty and does nothing. And that's the reason why there are no > securityRealm and authMethod controls. > > I guess that it is caused by some CDI "magic"? So I wonder is it a bug > or a feature? Can I use CommandController to test commands that implement > PrerequisiteCommandsProvider? > > Thanks, > Ivan > > > _______________________________________________ > forge-dev mailing listforge-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150703/5527b351/attachment-0001.html From ivan.st.ivanov at gmail.com Fri Jul 3 16:46:04 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Fri, 3 Jul 2015 23:46:04 +0300 Subject: [forge-dev] Some questions on wizard steps Message-ID: Hey everybody, It's me again, using a new thread for the sake of keeping stuff separated :) My next questions concern defining wizard steps. There we go: 1) Suppose I define a wizard. But already at the first window the user can say "I am done". And can press the Finish button. How can I specify in a wizard step that the Finish button is clickable. From the docs I got it is just by returning null from the next() method. But I want to have both the opportunity to go to the next step or finish everything immediately. So both Next and Finish buttons have to be enabled 2) That's a more tricky question. In a command window I want to give the opportunity to the user to define one or more security roles. Pay attention to the 'one or more' requirement: the user should be able to enter in one, two, three, four or *n* text fields the name of the role they want to add to the security constraint. How can I implement that? Thanks, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150703/6db2f50c/attachment.html From ggastald at redhat.com Fri Jul 3 18:19:49 2015 From: ggastald at redhat.com (George Gastaldi) Date: Fri, 3 Jul 2015 18:19:49 -0400 (EDT) Subject: [forge-dev] Interesting behavior of CommandController (bug or feature ; )) In-Reply-To: References: <55969AF5.7000808@redhat.com> Message-ID: <18orf4vyi2vvacqxkkkcppta.1435961985078@email.android.com> Hi Ivan, You should check if the ServletFacet is installed before adding ServletSetupWizard to the NavigationResultBuilder Best Regards, George Gastaldi
-------- Mensagem original --------
De: "Ivan St. Ivanov"
Data: 03/07/2015 17:32 (GMT-03:00)
Para: forge-dev List
Assunto: Re: [forge-dev] Interesting behavior of CommandController (bug or feature ; ))
Hey George, Thanks for your answer! :) Well, maybe I am mismatching two concepts. So, my command that implements PrerequisiteCommandsProvider does this: @Override public NavigationResult getPrerequisiteCommands(UIContext context) { NavigationResultBuilder builder = NavigationResultBuilder.create(); builder.add(ServletSetupWizard.class); return builder.build(); } Then, just before I execute the command controller thing, I install the Servlet facet for the corresponding Servlet version. But most probably installing a facet does not disable the prerequisite command? Cheers, Ivan On Fri, Jul 3, 2015 at 5:23 PM, George Gastaldi wrote: > Hi Ivan, > > Glad you decided to resume your work on the servlet security addon. > > When your command use a PreRequisiteCommandProvider, the initial step > might not be your command in question, but the commands to be executed > before that. That's why your setValueFor method might fail. > > What are the inputs returned in your test after you call initialize() > (commandController.getInputs()) ? > > Best Regards, > > George Gastaldi > > > On 07/03/2015 09:36 AM, Ivan St. Ivanov wrote: > > Hi everybody, > > Believe it or not, but I resumed my work on the Servlet Security addon > for Forge (https://issues.jboss.org/browse/FORGEPLUGINS-152) :) > > And I found something that I don't know whether is a bug or a feature. > If my Command class implements the PrerequisiteCommandsProvider and if I > try to use the CommandController in my integration test, then I have a > problem. Here is a sample code: > > try (CommandController commandController = testHarness > .createCommandController(SecuritySetupCommand.class, > project.getRoot())) > { > commandController.initialize(); > commandController.setValueFor("securityRealm", realm); > commandController.setValueFor("authMethod", authenticationMethod); > commandController.execute(); > } > > This code fails at the setValueFor method simply because the UI was not > initialized in the initialize method above it and there are no such inputs > like securityRealm and authMethod. > > I did some debugging and found that if SecuritySetupCommand implements > the PrerequisiteCommandsProvider interface, the > commandController.initialize() method does not > call PrerequisiteCommandsProvider#initializeUI method. Instead it > triggeres PrerequisiteCommandTransformer.DelegateWizard#initializeUI. Which > is empty and does nothing. And that's the reason why there are no > securityRealm and authMethod controls. > > I guess that it is caused by some CDI "magic"? So I wonder is it a bug > or a feature? Can I use CommandController to test commands that implement > PrerequisiteCommandsProvider? > > Thanks, > Ivan > > > _______________________________________________ > forge-dev mailing listforge-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150703/ca755bb7/attachment.html -------------- next part -------------- _______________________________________________ forge-dev mailing list forge-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev From ggastald at redhat.com Sat Jul 4 10:37:30 2015 From: ggastald at redhat.com (George Gastaldi) Date: Sat, 4 Jul 2015 10:37:30 -0400 (EDT) Subject: [forge-dev] Some questions on wizard steps In-Reply-To: References: Message-ID: Hey Ivan, 1) Finish is automatically enabled when the next steps are valid (do not require any input from the user) or is null.? 2) Use a UIInputMany and make it required. Best Regards, George Gastaldi
-------- Mensagem original --------
De: "Ivan St. Ivanov"
Data: 03/07/2015 17:46 (GMT-03:00)
Para: forge-dev List
Assunto: [forge-dev] Some questions on wizard steps
Hey everybody, It's me again, using a new thread for the sake of keeping stuff separated :) My next questions concern defining wizard steps. There we go: 1) Suppose I define a wizard. But already at the first window the user can say "I am done". And can press the Finish button. How can I specify in a wizard step that the Finish button is clickable. From the docs I got it is just by returning null from the next() method. But I want to have both the opportunity to go to the next step or finish everything immediately. So both Next and Finish buttons have to be enabled 2) That's a more tricky question. In a command window I want to give the opportunity to the user to define one or more security roles. Pay attention to the 'one or more' requirement: the user should be able to enter in one, two, three, four or *n* text fields the name of the role they want to add to the security constraint. How can I implement that? Thanks, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150704/e6bf2026/attachment.html -------------- next part -------------- _______________________________________________ forge-dev mailing list forge-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev From ivan.st.ivanov at gmail.com Sat Jul 4 10:46:40 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Sat, 4 Jul 2015 17:46:40 +0300 Subject: [forge-dev] Some questions on wizard steps In-Reply-To: References: Message-ID: Thanks a lot, George! I guess that if I make the List parameter an enum, it will appear as combo box(es) in the GUI? And to add to this question. Is it possible to define a combo box, where the user can both choose one of the options as well as add one by herself? On Jul 4, 2015 17:37, "George Gastaldi" wrote: > Hey Ivan, > > 1) Finish is automatically enabled when the next steps are valid (do not > require any input from the user) or is null. > > 2) Use a UIInputMany and make it required. > > Best Regards, > > George Gastaldi > > > -------- Mensagem original -------- > De: "Ivan St. Ivanov" > Data: 03/07/2015 17:46 (GMT-03:00) > Para: forge-dev List > Assunto: [forge-dev] Some questions on wizard steps > > > Hey everybody, > > It's me again, using a new thread for the sake of keeping stuff separated > :) > > My next questions concern defining wizard steps. There we go: > > 1) Suppose I define a wizard. But already at the first window the user can > say "I am done". And can press the Finish button. How can I specify in a > wizard step that the Finish button is clickable. From the docs I got it is > just by returning null from the next() method. But I want to have both the > opportunity to go to the next step or finish everything immediately. So > both Next and Finish buttons have to be enabled > > 2) That's a more tricky question. In a command window I want to give the > opportunity to the user to define one or more security roles. Pay attention > to the 'one or more' requirement: the user should be able to enter in one, > two, three, four or *n* text fields the name of the role they want to add > to the security constraint. How can I implement that? > > Thanks, > Ivan > > _______________________________________________ > 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/20150704/3588a9b5/attachment-0001.html From ggastald at redhat.com Sat Jul 4 11:35:52 2015 From: ggastald at redhat.com (George Gastaldi) Date: Sat, 4 Jul 2015 11:35:52 -0400 (EDT) Subject: [forge-dev] Some questions on wizard steps In-Reply-To: References: Message-ID: Hi Ivan, Yes, if you define the UISelectOne, it will be rendered as a combo box (non-editable). That depends on the InputType you choose (@WithAttributes(type=InputType.DROPDOWN)). As for your suggestion, you can use a UIInputMany and add a UICompleter to present some options when Ctrl+Space is pressed (although I think this may require some changes in the Eclipse plugin). Best Regards, George Gastaldu
-------- Mensagem original --------
De: "Ivan St. Ivanov"
Data: 04/07/2015 11:47 (GMT-03:00)
Para: forge-dev List
Assunto: Re: [forge-dev] Some questions on wizard steps
Thanks a lot, George! I guess that if I make the List parameter an enum, it will appear as combo box(es) in the GUI? And to add to this question. Is it possible to define a combo box, where the user can both choose one of the options as well as add one by herself? On Jul 4, 2015 17:37, "George Gastaldi" wrote: > Hey Ivan, > > 1) Finish is automatically enabled when the next steps are valid (do not > require any input from the user) or is null. > > 2) Use a UIInputMany and make it required. > > Best Regards, > > George Gastaldi > > > -------- Mensagem original -------- > De: "Ivan St. Ivanov" > Data: 03/07/2015 17:46 (GMT-03:00) > Para: forge-dev List > Assunto: [forge-dev] Some questions on wizard steps > > > Hey everybody, > > It's me again, using a new thread for the sake of keeping stuff separated > :) > > My next questions concern defining wizard steps. There we go: > > 1) Suppose I define a wizard. But already at the first window the user can > say "I am done". And can press the Finish button. How can I specify in a > wizard step that the Finish button is clickable. From the docs I got it is > just by returning null from the next() method. But I want to have both the > opportunity to go to the next step or finish everything immediately. So > both Next and Finish buttons have to be enabled > > 2) That's a more tricky question. In a command window I want to give the > opportunity to the user to define one or more security roles. Pay attention > to the 'one or more' requirement: the user should be able to enter in one, > two, three, four or *n* text fields the name of the role they want to add > to the security constraint. How can I implement that? > > Thanks, > Ivan > > _______________________________________________ > 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/20150704/57376576/attachment.html -------------- next part -------------- _______________________________________________ forge-dev mailing list forge-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev From ivan.st.ivanov at gmail.com Mon Jul 6 16:02:49 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Mon, 6 Jul 2015 23:02:49 +0300 Subject: [forge-dev] JPA facet isInstalled implementation Message-ID: Hi everybody, I am working on a project that is not mainstream Java EE. Its target is Tomcat, but it uses JPA 2.0 (Eclipselink). I have tailored the dependencies in the pom.xml as well as the persistence.xml. And now I want to use Forge to add some fields to the existing entities. What I noticed is that when I run the jpa-new-field command for the first time, it also installs the JPA facet. Which in turns adds some unwanted dependencies to my pom.xml and completely overwrites persistence.xml. I dig into the code and found that the isInstalled method of the JPA Facet returns true when persistence.xml file does not exist and when pom.xml does not contain some dependencies. These dependencies are different for JPA 2.0 and 2.1, but are basically Hibernate JPA API and the Java EE API. As a result of this, projects that don't target Java EE or that use different artifacts for it or for JPA are going to get their poms polluted and their persistence.xml files overwritten. So my proposal is to change the isInstalled method to only check for the presence of persistence.xml. What do you think? Regards, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150706/1b257cc5/attachment.html From ggastald at redhat.com Mon Jul 6 16:06:07 2015 From: ggastald at redhat.com (George Gastaldi) Date: Mon, 06 Jul 2015 17:06:07 -0300 Subject: [forge-dev] JPA facet isInstalled implementation In-Reply-To: References: Message-ID: <559ADFAF.2010604@redhat.com> Hi Ivan, I am not sure this is enough. How can you assure that no compilation errors would occur when @Entity or any other JPA-related class is used? Best Regards, George Gastaldi On 07/06/2015 05:02 PM, Ivan St. Ivanov wrote: > Hi everybody, > > I am working on a project that is not mainstream Java EE. Its target > is Tomcat, but it uses JPA 2.0 (Eclipselink). I have tailored the > dependencies in the pom.xml as well as the persistence.xml. > > And now I want to use Forge to add some fields to the existing > entities. What I noticed is that when I run the jpa-new-field command > for the first time, it also installs the JPA facet. Which in turns > adds some unwanted dependencies to my pom.xml and completely > overwrites persistence.xml. > > I dig into the code and found that the isInstalled method of the JPA > Facet returns true when persistence.xml file does not exist and when > pom.xml does not contain some dependencies. These dependencies are > different for JPA 2.0 and 2.1, but are basically Hibernate JPA API and > the Java EE API. > > As a result of this, projects that don't target Java EE or that use > different artifacts for it or for JPA are going to get their poms > polluted and their persistence.xml files overwritten. > > So my proposal is to change the isInstalled method to only check for > the presence of persistence.xml. What do you think? > > Regards, > Ivan > > > _______________________________________________ > 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/20150706/8f9db26a/attachment.html From ivan.st.ivanov at gmail.com Mon Jul 6 16:13:23 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Mon, 6 Jul 2015 23:13:23 +0300 Subject: [forge-dev] JPA facet isInstalled implementation In-Reply-To: <559ADFAF.2010604@redhat.com> References: <559ADFAF.2010604@redhat.com> Message-ID: Hi George, My idea is the following: if you don't have persistence.xml, then most probably you don't have the dependencies either. Definitely the facet is not installed, so Forge installs it for you by adding both the persistence.xml and the dependencies. But if you have persistence.xml already in your project in 99% of the cases you have already setup the dependencies as well. So the facet is there and Forge does not need to install it. Regards, Ivan On Mon, Jul 6, 2015 at 11:06 PM, George Gastaldi wrote: > Hi Ivan, > > I am not sure this is enough. How can you assure that no compilation > errors would occur when @Entity or any other JPA-related class is used? > > Best Regards, > > George Gastaldi > > > On 07/06/2015 05:02 PM, Ivan St. Ivanov wrote: > > Hi everybody, > > I am working on a project that is not mainstream Java EE. Its target is > Tomcat, but it uses JPA 2.0 (Eclipselink). I have tailored the dependencies > in the pom.xml as well as the persistence.xml. > > And now I want to use Forge to add some fields to the existing entities. > What I noticed is that when I run the jpa-new-field command for the first > time, it also installs the JPA facet. Which in turns adds some unwanted > dependencies to my pom.xml and completely overwrites persistence.xml. > > I dig into the code and found that the isInstalled method of the JPA > Facet returns true when persistence.xml file does not exist and when > pom.xml does not contain some dependencies. These dependencies are > different for JPA 2.0 and 2.1, but are basically Hibernate JPA API and the > Java EE API. > > As a result of this, projects that don't target Java EE or that use > different artifacts for it or for JPA are going to get their poms polluted > and their persistence.xml files overwritten. > > So my proposal is to change the isInstalled method to only check for the > presence of persistence.xml. What do you think? > > Regards, > Ivan > > > _______________________________________________ > forge-dev mailing listforge-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150706/37aaff73/attachment.html From ggastald at redhat.com Mon Jul 6 16:19:14 2015 From: ggastald at redhat.com (George Gastaldi) Date: Mon, 06 Jul 2015 17:19:14 -0300 Subject: [forge-dev] JPA facet isInstalled implementation In-Reply-To: References: <559ADFAF.2010604@redhat.com> Message-ID: <559AE2C2.70302@redhat.com> Hey Ivan, It seems that in your case the JPA 2.0 classes are defined in a different JAR (a different groupId/artifactId) ? Your idea might work, however, just make sure that the version attribute in the persistence.xml defines the installed facet version (JPAFacet_2_0 when version="2.0" and JPAFacet_2_1 when version="2.1"). Best Regards, George Gastaldi On 07/06/2015 05:13 PM, Ivan St. Ivanov wrote: > Hi George, > > My idea is the following: if you don't have persistence.xml, then most > probably you don't have the dependencies either. Definitely the facet > is not installed, so Forge installs it for you by adding both the > persistence.xml and the dependencies. > > But if you have persistence.xml already in your project in 99% of the > cases you have already setup the dependencies as well. So the facet is > there and Forge does not need to install it. > > Regards, > Ivan > > On Mon, Jul 6, 2015 at 11:06 PM, George Gastaldi > wrote: > > Hi Ivan, > > I am not sure this is enough. How can you assure that no > compilation errors would occur when @Entity or any other > JPA-related class is used? > > Best Regards, > > George Gastaldi > > > On 07/06/2015 05:02 PM, Ivan St. Ivanov wrote: >> Hi everybody, >> >> I am working on a project that is not mainstream Java EE. Its >> target is Tomcat, but it uses JPA 2.0 (Eclipselink). I have >> tailored the dependencies in the pom.xml as well as the >> persistence.xml. >> >> And now I want to use Forge to add some fields to the existing >> entities. What I noticed is that when I run the jpa-new-field >> command for the first time, it also installs the JPA facet. Which >> in turns adds some unwanted dependencies to my pom.xml and >> completely overwrites persistence.xml. >> >> I dig into the code and found that the isInstalled method of the >> JPA Facet returns true when persistence.xml file does not exist >> and when pom.xml does not contain some dependencies. These >> dependencies are different for JPA 2.0 and 2.1, but are basically >> Hibernate JPA API and the Java EE API. >> >> As a result of this, projects that don't target Java EE or that >> use different artifacts for it or for JPA are going to get their >> poms polluted and their persistence.xml files overwritten. >> >> So my proposal is to change the isInstalled method to only check >> for the presence of persistence.xml. What do you think? >> >> Regards, >> Ivan >> >> >> _______________________________________________ >> 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 > > > > > _______________________________________________ > 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/20150706/8f6f2f59/attachment-0001.html From ivan.st.ivanov at gmail.com Mon Jul 6 16:24:43 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Mon, 6 Jul 2015 23:24:43 +0300 Subject: [forge-dev] JPA facet isInstalled implementation In-Reply-To: <559AE2C2.70302@redhat.com> References: <559ADFAF.2010604@redhat.com> <559AE2C2.70302@redhat.com> Message-ID: Hi George, As I mentioned, I am using Eclipselink and have directly the dependency org.eclipse.persistence:eclipselink. On top of that, I don't have the Java EE API dependency. My persistence.xml is fine. What I really want here is when I add a new field Forge to find out that this project has already persistence.xml and not try to rebuild it just because I am missing some dependencies in the pom.xml. Cheers, Ivan On Mon, Jul 6, 2015 at 11:19 PM, George Gastaldi wrote: > Hey Ivan, > > It seems that in your case the JPA 2.0 classes are defined in a different > JAR (a different groupId/artifactId) ? > Your idea might work, however, just make sure that the version attribute > in the persistence.xml defines the installed facet version (JPAFacet_2_0 > when version="2.0" and JPAFacet_2_1 when version="2.1"). > > Best Regards, > George Gastaldi > > > On 07/06/2015 05:13 PM, Ivan St. Ivanov wrote: > > Hi George, > > My idea is the following: if you don't have persistence.xml, then most > probably you don't have the dependencies either. Definitely the facet is > not installed, so Forge installs it for you by adding both the > persistence.xml and the dependencies. > > But if you have persistence.xml already in your project in 99% of the > cases you have already setup the dependencies as well. So the facet is > there and Forge does not need to install it. > > Regards, > Ivan > > On Mon, Jul 6, 2015 at 11:06 PM, George Gastaldi > wrote: > >> Hi Ivan, >> >> I am not sure this is enough. How can you assure that no compilation >> errors would occur when @Entity or any other JPA-related class is used? >> >> Best Regards, >> >> George Gastaldi >> >> >> On 07/06/2015 05:02 PM, Ivan St. Ivanov wrote: >> >> Hi everybody, >> >> I am working on a project that is not mainstream Java EE. Its target is >> Tomcat, but it uses JPA 2.0 (Eclipselink). I have tailored the dependencies >> in the pom.xml as well as the persistence.xml. >> >> And now I want to use Forge to add some fields to the existing >> entities. What I noticed is that when I run the jpa-new-field command for >> the first time, it also installs the JPA facet. Which in turns adds some >> unwanted dependencies to my pom.xml and completely overwrites >> persistence.xml. >> >> I dig into the code and found that the isInstalled method of the JPA >> Facet returns true when persistence.xml file does not exist and when >> pom.xml does not contain some dependencies. These dependencies are >> different for JPA 2.0 and 2.1, but are basically Hibernate JPA API and the >> Java EE API. >> >> As a result of this, projects that don't target Java EE or that use >> different artifacts for it or for JPA are going to get their poms polluted >> and their persistence.xml files overwritten. >> >> So my proposal is to change the isInstalled method to only check for >> the presence of persistence.xml. What do you think? >> >> Regards, >> Ivan >> >> >> _______________________________________________ >> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >> > > > > _______________________________________________ > forge-dev mailing listforge-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150706/df2d1dc4/attachment.html From ggastald at redhat.com Mon Jul 6 16:30:45 2015 From: ggastald at redhat.com (George Gastaldi) Date: Mon, 6 Jul 2015 16:30:45 -0400 (EDT) Subject: [forge-dev] JPA facet isInstalled implementation In-Reply-To: References: <559ADFAF.2010604@redhat.com> <559AE2C2.70302@redhat.com> Message-ID: Right, so the easiest way to solve this is to add this dependency to the JPAFacet_2_0.getRequiredDependencies().? But I am not opposed on your proposed change, as long as no compilation issues happen. Thanks,George Gastaldi
-------- Mensagem original --------
De: "Ivan St. Ivanov"
Data: 06/07/2015 17:25 (GMT-03:00)
Para: forge-dev List
Assunto: Re: [forge-dev] JPA facet isInstalled implementation
Hi George, As I mentioned, I am using Eclipselink and have directly the dependency org.eclipse.persistence:eclipselink. On top of that, I don't have the Java EE API dependency. My persistence.xml is fine. What I really want here is when I add a new field Forge to find out that this project has already persistence.xml and not try to rebuild it just because I am missing some dependencies in the pom.xml. Cheers, Ivan On Mon, Jul 6, 2015 at 11:19 PM, George Gastaldi wrote: > Hey Ivan, > > It seems that in your case the JPA 2.0 classes are defined in a different > JAR (a different groupId/artifactId) ? > Your idea might work, however, just make sure that the version attribute > in the persistence.xml defines the installed facet version (JPAFacet_2_0 > when version="2.0" and JPAFacet_2_1 when version="2.1"). > > Best Regards, > George Gastaldi > > > On 07/06/2015 05:13 PM, Ivan St. Ivanov wrote: > > Hi George, > > My idea is the following: if you don't have persistence.xml, then most > probably you don't have the dependencies either. Definitely the facet is > not installed, so Forge installs it for you by adding both the > persistence.xml and the dependencies. > > But if you have persistence.xml already in your project in 99% of the > cases you have already setup the dependencies as well. So the facet is > there and Forge does not need to install it. > > Regards, > Ivan > > On Mon, Jul 6, 2015 at 11:06 PM, George Gastaldi > wrote: > >> Hi Ivan, >> >> I am not sure this is enough. How can you assure that no compilation >> errors would occur when @Entity or any other JPA-related class is used? >> >> Best Regards, >> >> George Gastaldi >> >> >> On 07/06/2015 05:02 PM, Ivan St. Ivanov wrote: >> >> Hi everybody, >> >> I am working on a project that is not mainstream Java EE. Its target is >> Tomcat, but it uses JPA 2.0 (Eclipselink). I have tailored the dependencies >> in the pom.xml as well as the persistence.xml. >> >> And now I want to use Forge to add some fields to the existing >> entities. What I noticed is that when I run the jpa-new-field command for >> the first time, it also installs the JPA facet. Which in turns adds some >> unwanted dependencies to my pom.xml and completely overwrites >> persistence.xml. >> >> I dig into the code and found that the isInstalled method of the JPA >> Facet returns true when persistence.xml file does not exist and when >> pom.xml does not contain some dependencies. These dependencies are >> different for JPA 2.0 and 2.1, but are basically Hibernate JPA API and the >> Java EE API. >> >> As a result of this, projects that don't target Java EE or that use >> different artifacts for it or for JPA are going to get their poms polluted >> and their persistence.xml files overwritten. >> >> So my proposal is to change the isInstalled method to only check for >> the presence of persistence.xml. What do you think? >> >> Regards, >> Ivan >> >> >> _______________________________________________ >> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >> > > > > _______________________________________________ > forge-dev mailing listforge-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150706/15e43c5f/attachment.html -------------- next part -------------- _______________________________________________ forge-dev mailing list forge-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev From ivan.st.ivanov at gmail.com Mon Jul 6 16:32:57 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Mon, 6 Jul 2015 23:32:57 +0300 Subject: [forge-dev] JPA facet isInstalled implementation In-Reply-To: References: <559ADFAF.2010604@redhat.com> <559AE2C2.70302@redhat.com> Message-ID: Well, besides adding this, we should think of adding also the openjpa dependency, also the hibernate impl dependency and also removing the Java EE 6 dependency. And we also have to make a more sophisticated check to make sure we apply 'or' instead of 'and' when checking for the presence of these dependencies... Too complex and error prone in my opinion, don't you think? On Mon, Jul 6, 2015 at 11:30 PM, George Gastaldi wrote: > Right, so the easiest way to solve this is to add this dependency to the > JPAFacet_2_0.getRequiredDependencies(). > > But I am not opposed on your proposed change, as long as no compilation > issues happen. > > Thanks, > George Gastaldi > > > -------- Mensagem original -------- > De: "Ivan St. Ivanov" > Data: 06/07/2015 17:25 (GMT-03:00) > Para: forge-dev List > Assunto: Re: [forge-dev] JPA facet isInstalled implementation > > > Hi George, > > As I mentioned, I am using Eclipselink and have directly the > dependency org.eclipse.persistence:eclipselink. On top of that, I don't > have the Java EE API dependency. My persistence.xml is fine. > > What I really want here is when I add a new field Forge to find out that > this project has already persistence.xml and not try to rebuild it just > because I am missing some dependencies in the pom.xml. > > Cheers, > Ivan > > On Mon, Jul 6, 2015 at 11:19 PM, George Gastaldi > wrote: > >> Hey Ivan, >> >> It seems that in your case the JPA 2.0 classes are defined in a different >> JAR (a different groupId/artifactId) ? >> Your idea might work, however, just make sure that the version attribute >> in the persistence.xml defines the installed facet version (JPAFacet_2_0 >> when version="2.0" and JPAFacet_2_1 when version="2.1"). >> >> Best Regards, >> George Gastaldi >> >> >> On 07/06/2015 05:13 PM, Ivan St. Ivanov wrote: >> >> Hi George, >> >> My idea is the following: if you don't have persistence.xml, then most >> probably you don't have the dependencies either. Definitely the facet is >> not installed, so Forge installs it for you by adding both the >> persistence.xml and the dependencies. >> >> But if you have persistence.xml already in your project in 99% of the >> cases you have already setup the dependencies as well. So the facet is >> there and Forge does not need to install it. >> >> Regards, >> Ivan >> >> On Mon, Jul 6, 2015 at 11:06 PM, George Gastaldi >> wrote: >> >>> Hi Ivan, >>> >>> I am not sure this is enough. How can you assure that no compilation >>> errors would occur when @Entity or any other JPA-related class is used? >>> >>> Best Regards, >>> >>> George Gastaldi >>> >>> >>> On 07/06/2015 05:02 PM, Ivan St. Ivanov wrote: >>> >>> Hi everybody, >>> >>> I am working on a project that is not mainstream Java EE. Its target >>> is Tomcat, but it uses JPA 2.0 (Eclipselink). I have tailored the >>> dependencies in the pom.xml as well as the persistence.xml. >>> >>> And now I want to use Forge to add some fields to the existing >>> entities. What I noticed is that when I run the jpa-new-field command for >>> the first time, it also installs the JPA facet. Which in turns adds some >>> unwanted dependencies to my pom.xml and completely overwrites >>> persistence.xml. >>> >>> I dig into the code and found that the isInstalled method of the JPA >>> Facet returns true when persistence.xml file does not exist and when >>> pom.xml does not contain some dependencies. These dependencies are >>> different for JPA 2.0 and 2.1, but are basically Hibernate JPA API and the >>> Java EE API. >>> >>> As a result of this, projects that don't target Java EE or that use >>> different artifacts for it or for JPA are going to get their poms polluted >>> and their persistence.xml files overwritten. >>> >>> So my proposal is to change the isInstalled method to only check for >>> the presence of persistence.xml. What do you think? >>> >>> Regards, >>> Ivan >>> >>> >>> _______________________________________________ >>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >>> >> >> >> >> _______________________________________________ >> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >> > > > _______________________________________________ > 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/20150706/4fdff1e2/attachment-0001.html From ggastald at redhat.com Mon Jul 6 16:35:19 2015 From: ggastald at redhat.com (George Gastaldi) Date: Mon, 6 Jul 2015 16:35:19 -0400 (EDT) Subject: [forge-dev] JPA facet isInstalled implementation In-Reply-To: References: <559ADFAF.2010604@redhat.com> <559AE2C2.70302@redhat.com> Message-ID: We already got these PersistenceProvider implementations. What if we added a isInstalled(Project) on top of them?
-------- Mensagem original --------
De: "Ivan St. Ivanov"
Data: 06/07/2015 17:33 (GMT-03:00)
Para: forge-dev List
Assunto: Re: [forge-dev] JPA facet isInstalled implementation
Well, besides adding this, we should think of adding also the openjpa dependency, also the hibernate impl dependency and also removing the Java EE 6 dependency. And we also have to make a more sophisticated check to make sure we apply 'or' instead of 'and' when checking for the presence of these dependencies... Too complex and error prone in my opinion, don't you think? On Mon, Jul 6, 2015 at 11:30 PM, George Gastaldi wrote: > Right, so the easiest way to solve this is to add this dependency to the > JPAFacet_2_0.getRequiredDependencies(). > > But I am not opposed on your proposed change, as long as no compilation > issues happen. > > Thanks, > George Gastaldi > > > -------- Mensagem original -------- > De: "Ivan St. Ivanov" > Data: 06/07/2015 17:25 (GMT-03:00) > Para: forge-dev List > Assunto: Re: [forge-dev] JPA facet isInstalled implementation > > > Hi George, > > As I mentioned, I am using Eclipselink and have directly the > dependency org.eclipse.persistence:eclipselink. On top of that, I don't > have the Java EE API dependency. My persistence.xml is fine. > > What I really want here is when I add a new field Forge to find out that > this project has already persistence.xml and not try to rebuild it just > because I am missing some dependencies in the pom.xml. > > Cheers, > Ivan > > On Mon, Jul 6, 2015 at 11:19 PM, George Gastaldi > wrote: > >> Hey Ivan, >> >> It seems that in your case the JPA 2.0 classes are defined in a different >> JAR (a different groupId/artifactId) ? >> Your idea might work, however, just make sure that the version attribute >> in the persistence.xml defines the installed facet version (JPAFacet_2_0 >> when version="2.0" and JPAFacet_2_1 when version="2.1"). >> >> Best Regards, >> George Gastaldi >> >> >> On 07/06/2015 05:13 PM, Ivan St. Ivanov wrote: >> >> Hi George, >> >> My idea is the following: if you don't have persistence.xml, then most >> probably you don't have the dependencies either. Definitely the facet is >> not installed, so Forge installs it for you by adding both the >> persistence.xml and the dependencies. >> >> But if you have persistence.xml already in your project in 99% of the >> cases you have already setup the dependencies as well. So the facet is >> there and Forge does not need to install it. >> >> Regards, >> Ivan >> >> On Mon, Jul 6, 2015 at 11:06 PM, George Gastaldi >> wrote: >> >>> Hi Ivan, >>> >>> I am not sure this is enough. How can you assure that no compilation >>> errors would occur when @Entity or any other JPA-related class is used? >>> >>> Best Regards, >>> >>> George Gastaldi >>> >>> >>> On 07/06/2015 05:02 PM, Ivan St. Ivanov wrote: >>> >>> Hi everybody, >>> >>> I am working on a project that is not mainstream Java EE. Its target >>> is Tomcat, but it uses JPA 2.0 (Eclipselink). I have tailored the >>> dependencies in the pom.xml as well as the persistence.xml. >>> >>> And now I want to use Forge to add some fields to the existing >>> entities. What I noticed is that when I run the jpa-new-field command for >>> the first time, it also installs the JPA facet. Which in turns adds some >>> unwanted dependencies to my pom.xml and completely overwrites >>> persistence.xml. >>> >>> I dig into the code and found that the isInstalled method of the JPA >>> Facet returns true when persistence.xml file does not exist and when >>> pom.xml does not contain some dependencies. These dependencies are >>> different for JPA 2.0 and 2.1, but are basically Hibernate JPA API and the >>> Java EE API. >>> >>> As a result of this, projects that don't target Java EE or that use >>> different artifacts for it or for JPA are going to get their poms polluted >>> and their persistence.xml files overwritten. >>> >>> So my proposal is to change the isInstalled method to only check for >>> the presence of persistence.xml. What do you think? >>> >>> Regards, >>> Ivan >>> >>> >>> _______________________________________________ >>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >>> >> >> >> >> _______________________________________________ >> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >> > > > _______________________________________________ > 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/20150706/9bcf2fb7/attachment.html -------------- next part -------------- _______________________________________________ forge-dev mailing list forge-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev From ivan.st.ivanov at gmail.com Mon Jul 6 16:39:52 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Mon, 6 Jul 2015 23:39:52 +0300 Subject: [forge-dev] JPA facet isInstalled implementation In-Reply-To: References: <559ADFAF.2010604@redhat.com> <559AE2C2.70302@redhat.com> Message-ID: You mean, listing all the existing persistence providers and call their listDependencies() method? This sounds correct. But I am not sure how it will perform. Remember, this routine will be called each time a new entity or new field command is run... On Mon, Jul 6, 2015 at 11:35 PM, George Gastaldi wrote: > We already got these PersistenceProvider implementations. What if we added > a isInstalled(Project) on top of them? > > > -------- Mensagem original -------- > De: "Ivan St. Ivanov" > Data: 06/07/2015 17:33 (GMT-03:00) > Para: forge-dev List > Assunto: Re: [forge-dev] JPA facet isInstalled implementation > > > Well, besides adding this, we should think of adding also the openjpa > dependency, also the hibernate impl dependency and also removing the Java > EE 6 dependency. And we also have to make a more sophisticated check to > make sure we apply 'or' instead of 'and' when checking for the presence of > these dependencies... > > Too complex and error prone in my opinion, don't you think? > > On Mon, Jul 6, 2015 at 11:30 PM, George Gastaldi > wrote: > >> Right, so the easiest way to solve this is to add this dependency to the >> JPAFacet_2_0.getRequiredDependencies(). >> >> But I am not opposed on your proposed change, as long as no compilation >> issues happen. >> >> Thanks, >> George Gastaldi >> >> >> -------- Mensagem original -------- >> De: "Ivan St. Ivanov" >> Data: 06/07/2015 17:25 (GMT-03:00) >> Para: forge-dev List >> Assunto: Re: [forge-dev] JPA facet isInstalled implementation >> >> >> Hi George, >> >> As I mentioned, I am using Eclipselink and have directly the >> dependency org.eclipse.persistence:eclipselink. On top of that, I don't >> have the Java EE API dependency. My persistence.xml is fine. >> >> What I really want here is when I add a new field Forge to find out that >> this project has already persistence.xml and not try to rebuild it just >> because I am missing some dependencies in the pom.xml. >> >> Cheers, >> Ivan >> >> On Mon, Jul 6, 2015 at 11:19 PM, George Gastaldi >> wrote: >> >>> Hey Ivan, >>> >>> It seems that in your case the JPA 2.0 classes are defined in a >>> different JAR (a different groupId/artifactId) ? >>> Your idea might work, however, just make sure that the version attribute >>> in the persistence.xml defines the installed facet version (JPAFacet_2_0 >>> when version="2.0" and JPAFacet_2_1 when version="2.1"). >>> >>> Best Regards, >>> George Gastaldi >>> >>> >>> On 07/06/2015 05:13 PM, Ivan St. Ivanov wrote: >>> >>> Hi George, >>> >>> My idea is the following: if you don't have persistence.xml, then most >>> probably you don't have the dependencies either. Definitely the facet is >>> not installed, so Forge installs it for you by adding both the >>> persistence.xml and the dependencies. >>> >>> But if you have persistence.xml already in your project in 99% of the >>> cases you have already setup the dependencies as well. So the facet is >>> there and Forge does not need to install it. >>> >>> Regards, >>> Ivan >>> >>> On Mon, Jul 6, 2015 at 11:06 PM, George Gastaldi >>> wrote: >>> >>>> Hi Ivan, >>>> >>>> I am not sure this is enough. How can you assure that no compilation >>>> errors would occur when @Entity or any other JPA-related class is used? >>>> >>>> Best Regards, >>>> >>>> George Gastaldi >>>> >>>> >>>> On 07/06/2015 05:02 PM, Ivan St. Ivanov wrote: >>>> >>>> Hi everybody, >>>> >>>> I am working on a project that is not mainstream Java EE. Its target >>>> is Tomcat, but it uses JPA 2.0 (Eclipselink). I have tailored the >>>> dependencies in the pom.xml as well as the persistence.xml. >>>> >>>> And now I want to use Forge to add some fields to the existing >>>> entities. What I noticed is that when I run the jpa-new-field command for >>>> the first time, it also installs the JPA facet. Which in turns adds some >>>> unwanted dependencies to my pom.xml and completely overwrites >>>> persistence.xml. >>>> >>>> I dig into the code and found that the isInstalled method of the JPA >>>> Facet returns true when persistence.xml file does not exist and when >>>> pom.xml does not contain some dependencies. These dependencies are >>>> different for JPA 2.0 and 2.1, but are basically Hibernate JPA API and the >>>> Java EE API. >>>> >>>> As a result of this, projects that don't target Java EE or that use >>>> different artifacts for it or for JPA are going to get their poms polluted >>>> and their persistence.xml files overwritten. >>>> >>>> So my proposal is to change the isInstalled method to only check for >>>> the presence of persistence.xml. What do you think? >>>> >>>> Regards, >>>> Ivan >>>> >>>> >>>> _______________________________________________ >>>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >>>> >>> >>> >>> >>> _______________________________________________ >>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >>> >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150706/da8ce42f/attachment-0001.html From ggastald at redhat.com Mon Jul 6 16:54:04 2015 From: ggastald at redhat.com (George Gastaldi) Date: Mon, 06 Jul 2015 17:54:04 -0300 Subject: [forge-dev] JPA facet isInstalled implementation In-Reply-To: References: <559ADFAF.2010604@redhat.com> <559AE2C2.70302@redhat.com> Message-ID: <559AEAEC.2020101@redhat.com> Right, we need to make isInstalled() fast, good point. I think it's ok to assume that the facet is installed by checking the existence and the version attribute in the persistence.xml. Maybe we could add a getPersistenceProvider() to JPAFacet to let the user know which implementation is used in case it needs more info, WDYT? Best Regards, George Gastaldi On 07/06/2015 05:39 PM, Ivan St. Ivanov wrote: > You mean, listing all the existing persistence providers and call > their listDependencies() method? This sounds correct. But I am not > sure how it will perform. Remember, this routine will be called each > time a new entity or new field command is run... > > On Mon, Jul 6, 2015 at 11:35 PM, George Gastaldi > wrote: > > We already got these PersistenceProvider implementations. What if > we added a isInstalled(Project) on top of them? > > > -------- Mensagem original -------- > De: "Ivan St. Ivanov" > > Data: 06/07/2015 17:33 (GMT-03:00) > Para: forge-dev List > > Assunto: Re: [forge-dev] JPA facet isInstalled implementation > > > Well, besides adding this, we should think of adding also the > openjpa dependency, also the hibernate impl dependency and also > removing the Java EE 6 dependency. And we also have to make a more > sophisticated check to make sure we apply 'or' instead of 'and' > when checking for the presence of these dependencies... > > Too complex and error prone in my opinion, don't you think? > > On Mon, Jul 6, 2015 at 11:30 PM, George Gastaldi > > wrote: > > Right, so the easiest way to solve this is to add this > dependency to the JPAFacet_2_0.getRequiredDependencies(). > > But I am not opposed on your proposed change, as long as no > compilation issues happen. > > Thanks, > George Gastaldi > > > -------- Mensagem original -------- > De: "Ivan St. Ivanov" > > Data: 06/07/2015 17:25 (GMT-03:00) > Para: forge-dev List > > Assunto: Re: [forge-dev] JPA facet isInstalled implementation > > > Hi George, > > As I mentioned, I am using Eclipselink and have directly the > dependency org.eclipse.persistence:eclipselink. On top of > that, I don't have the Java EE API dependency. My > persistence.xml is fine. > > What I really want here is when I add a new field Forge to > find out that this project has already persistence.xml and not > try to rebuild it just because I am missing some dependencies > in the pom.xml. > > Cheers, > Ivan > > On Mon, Jul 6, 2015 at 11:19 PM, George Gastaldi > > wrote: > > Hey Ivan, > > It seems that in your case the JPA 2.0 classes are defined > in a different JAR (a different groupId/artifactId) ? > Your idea might work, however, just make sure that the > version attribute in the persistence.xml defines the > installed facet version (JPAFacet_2_0 when version="2.0" > and JPAFacet_2_1 when version="2.1"). > > Best Regards, > George Gastaldi > > > On 07/06/2015 05:13 PM, Ivan St. Ivanov wrote: >> Hi George, >> >> My idea is the following: if you don't have >> persistence.xml, then most probably you don't have the >> dependencies either. Definitely the facet is not >> installed, so Forge installs it for you by adding both >> the persistence.xml and the dependencies. >> >> But if you have persistence.xml already in your project >> in 99% of the cases you have already setup the >> dependencies as well. So the facet is there and Forge >> does not need to install it. >> >> Regards, >> Ivan >> >> On Mon, Jul 6, 2015 at 11:06 PM, George Gastaldi >> > wrote: >> >> Hi Ivan, >> >> I am not sure this is enough. How can you assure that >> no compilation errors would occur when @Entity or any >> other JPA-related class is used? >> >> Best Regards, >> >> George Gastaldi >> >> >> On 07/06/2015 05:02 PM, Ivan St. Ivanov wrote: >>> Hi everybody, >>> >>> I am working on a project that is not mainstream >>> Java EE. Its target is Tomcat, but it uses JPA 2.0 >>> (Eclipselink). I have tailored the dependencies in >>> the pom.xml as well as the persistence.xml. >>> >>> And now I want to use Forge to add some fields to >>> the existing entities. What I noticed is that when I >>> run the jpa-new-field command for the first time, it >>> also installs the JPA facet. Which in turns adds >>> some unwanted dependencies to my pom.xml and >>> completely overwrites persistence.xml. >>> >>> I dig into the code and found that the isInstalled >>> method of the JPA Facet returns true when >>> persistence.xml file does not exist and when pom.xml >>> does not contain some dependencies. These >>> dependencies are different for JPA 2.0 and 2.1, but >>> are basically Hibernate JPA API and the Java EE API. >>> >>> As a result of this, projects that don't target Java >>> EE or that use different artifacts for it or for JPA >>> are going to get their poms polluted and their >>> persistence.xml files overwritten. >>> >>> So my proposal is to change the isInstalled method >>> to only check for the presence of persistence.xml. >>> What do you think? >>> >>> Regards, >>> Ivan >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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/20150706/3cb1a981/attachment-0001.html From ivan.st.ivanov at gmail.com Tue Jul 7 03:55:18 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Tue, 7 Jul 2015 10:55:18 +0300 Subject: [forge-dev] JPA facet isInstalled implementation In-Reply-To: <559AEAEC.2020101@redhat.com> References: <559ADFAF.2010604@redhat.com> <559AE2C2.70302@redhat.com> <559AEAEC.2020101@redhat.com> Message-ID: Hi George, Yes, having this information (about the persistence provider) is very valuable. Some months ago I was even thinking about the fact that we miss such an option - once you run the persistence setup command, you lose the information about the persistence provider. I would however create two separate JIRAs for this things (supposing we all agree that we'll change the isInstalled method). They seem to be independent of each other and one of them is much more urgent, at least for me ;) Cheers, Ivan On Mon, Jul 6, 2015 at 11:54 PM, George Gastaldi wrote: > Right, we need to make isInstalled() fast, good point. > > I think it's ok to assume that the facet is installed by checking the > existence and the version attribute in the persistence.xml. Maybe we could > add a getPersistenceProvider() to JPAFacet to let the user know which > implementation is used in case it needs more info, WDYT? > > Best Regards, > > George Gastaldi > > > On 07/06/2015 05:39 PM, Ivan St. Ivanov wrote: > > You mean, listing all the existing persistence providers and call their > listDependencies() method? This sounds correct. But I am not sure how it > will perform. Remember, this routine will be called each time a new entity > or new field command is run... > > On Mon, Jul 6, 2015 at 11:35 PM, George Gastaldi > wrote: > >> We already got these PersistenceProvider implementations. What if we >> added a isInstalled(Project) on top of them? >> >> >> -------- Mensagem original -------- >> De: "Ivan St. Ivanov" >> Data: 06/07/2015 17:33 (GMT-03:00) >> Para: forge-dev List >> Assunto: Re: [forge-dev] JPA facet isInstalled implementation >> >> >> Well, besides adding this, we should think of adding also the openjpa >> dependency, also the hibernate impl dependency and also removing the Java >> EE 6 dependency. And we also have to make a more sophisticated check to >> make sure we apply 'or' instead of 'and' when checking for the presence of >> these dependencies... >> >> Too complex and error prone in my opinion, don't you think? >> >> On Mon, Jul 6, 2015 at 11:30 PM, George Gastaldi >> wrote: >> >>> Right, so the easiest way to solve this is to add this dependency to >>> the JPAFacet_2_0.getRequiredDependencies(). >>> >>> But I am not opposed on your proposed change, as long as no >>> compilation issues happen. >>> >>> Thanks, >>> George Gastaldi >>> >>> >>> -------- Mensagem original -------- >>> De: "Ivan St. Ivanov" >>> Data: 06/07/2015 17:25 (GMT-03:00) >>> Para: forge-dev List >>> Assunto: Re: [forge-dev] JPA facet isInstalled implementation >>> >>> >>> Hi George, >>> >>> As I mentioned, I am using Eclipselink and have directly the >>> dependency org.eclipse.persistence:eclipselink. On top of that, I don't >>> have the Java EE API dependency. My persistence.xml is fine. >>> >>> What I really want here is when I add a new field Forge to find out >>> that this project has already persistence.xml and not try to rebuild it >>> just because I am missing some dependencies in the pom.xml. >>> >>> Cheers, >>> Ivan >>> >>> On Mon, Jul 6, 2015 at 11:19 PM, George Gastaldi >>> wrote: >>> >>>> Hey Ivan, >>>> >>>> It seems that in your case the JPA 2.0 classes are defined in a >>>> different JAR (a different groupId/artifactId) ? >>>> Your idea might work, however, just make sure that the version >>>> attribute in the persistence.xml defines the installed facet version >>>> (JPAFacet_2_0 when version="2.0" and JPAFacet_2_1 when version="2.1"). >>>> >>>> Best Regards, >>>> George Gastaldi >>>> >>>> >>>> On 07/06/2015 05:13 PM, Ivan St. Ivanov wrote: >>>> >>>> Hi George, >>>> >>>> My idea is the following: if you don't have persistence.xml, then >>>> most probably you don't have the dependencies either. Definitely the facet >>>> is not installed, so Forge installs it for you by adding both the >>>> persistence.xml and the dependencies. >>>> >>>> But if you have persistence.xml already in your project in 99% of the >>>> cases you have already setup the dependencies as well. So the facet is >>>> there and Forge does not need to install it. >>>> >>>> Regards, >>>> Ivan >>>> >>>> On Mon, Jul 6, 2015 at 11:06 PM, George Gastaldi >>>> wrote: >>>> >>>>> Hi Ivan, >>>>> >>>>> I am not sure this is enough. How can you assure that no compilation >>>>> errors would occur when @Entity or any other JPA-related class is used? >>>>> >>>>> Best Regards, >>>>> >>>>> George Gastaldi >>>>> >>>>> >>>>> On 07/06/2015 05:02 PM, Ivan St. Ivanov wrote: >>>>> >>>>> Hi everybody, >>>>> >>>>> I am working on a project that is not mainstream Java EE. Its target >>>>> is Tomcat, but it uses JPA 2.0 (Eclipselink). I have tailored the >>>>> dependencies in the pom.xml as well as the persistence.xml. >>>>> >>>>> And now I want to use Forge to add some fields to the existing >>>>> entities. What I noticed is that when I run the jpa-new-field command for >>>>> the first time, it also installs the JPA facet. Which in turns adds some >>>>> unwanted dependencies to my pom.xml and completely overwrites >>>>> persistence.xml. >>>>> >>>>> I dig into the code and found that the isInstalled method of the JPA >>>>> Facet returns true when persistence.xml file does not exist and when >>>>> pom.xml does not contain some dependencies. These dependencies are >>>>> different for JPA 2.0 and 2.1, but are basically Hibernate JPA API and the >>>>> Java EE API. >>>>> >>>>> As a result of this, projects that don't target Java EE or that use >>>>> different artifacts for it or for JPA are going to get their poms polluted >>>>> and their persistence.xml files overwritten. >>>>> >>>>> So my proposal is to change the isInstalled method to only check for >>>>> the presence of persistence.xml. What do you think? >>>>> >>>>> Regards, >>>>> Ivan >>>>> >>>>> >>>>> _______________________________________________ >>>>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >>>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > _______________________________________________ > forge-dev mailing listforge-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150707/196a3c70/attachment-0001.html From ggastald at redhat.com Tue Jul 7 09:32:24 2015 From: ggastald at redhat.com (George Gastaldi) Date: Tue, 7 Jul 2015 09:32:24 -0400 (EDT) Subject: [forge-dev] JPA facet isInstalled implementation In-Reply-To: References: <559AEAEC.2020101@redhat.com> Message-ID: Sure, that's fine.?Thank you Ivan!
-------- Mensagem original --------
De: "Ivan St. Ivanov"
Data: 07/07/2015 04:55 (GMT-03:00)
Para: forge-dev List
Assunto: Re: [forge-dev] JPA facet isInstalled implementation
Hi George, Yes, having this information (about the persistence provider) is very valuable. Some months ago I was even thinking about the fact that we miss such an option - once you run the persistence setup command, you lose the information about the persistence provider. I would however create two separate JIRAs for this things (supposing we all agree that we'll change the isInstalled method). They seem to be independent of each other and one of them is much more urgent, at least for me ;) Cheers, Ivan On Mon, Jul 6, 2015 at 11:54 PM, George Gastaldi wrote: > Right, we need to make isInstalled() fast, good point. > > I think it's ok to assume that the facet is installed by checking the > existence and the version attribute in the persistence.xml. Maybe we could > add a getPersistenceProvider() to JPAFacet to let the user know which > implementation is used in case it needs more info, WDYT? > > Best Regards, > > George Gastaldi > > > On 07/06/2015 05:39 PM, Ivan St. Ivanov wrote: > > You mean, listing all the existing persistence providers and call their > listDependencies() method? This sounds correct. But I am not sure how it > will perform. Remember, this routine will be called each time a new entity > or new field command is run... > > On Mon, Jul 6, 2015 at 11:35 PM, George Gastaldi > wrote: > >> We already got these PersistenceProvider implementations. What if we >> added a isInstalled(Project) on top of them? >> >> >> -------- Mensagem original -------- >> De: "Ivan St. Ivanov" >> Data: 06/07/2015 17:33 (GMT-03:00) >> Para: forge-dev List >> Assunto: Re: [forge-dev] JPA facet isInstalled implementation >> >> >> Well, besides adding this, we should think of adding also the openjpa >> dependency, also the hibernate impl dependency and also removing the Java >> EE 6 dependency. And we also have to make a more sophisticated check to >> make sure we apply 'or' instead of 'and' when checking for the presence of >> these dependencies... >> >> Too complex and error prone in my opinion, don't you think? >> >> On Mon, Jul 6, 2015 at 11:30 PM, George Gastaldi >> wrote: >> >>> Right, so the easiest way to solve this is to add this dependency to >>> the JPAFacet_2_0.getRequiredDependencies(). >>> >>> But I am not opposed on your proposed change, as long as no >>> compilation issues happen. >>> >>> Thanks, >>> George Gastaldi >>> >>> >>> -------- Mensagem original -------- >>> De: "Ivan St. Ivanov" >>> Data: 06/07/2015 17:25 (GMT-03:00) >>> Para: forge-dev List >>> Assunto: Re: [forge-dev] JPA facet isInstalled implementation >>> >>> >>> Hi George, >>> >>> As I mentioned, I am using Eclipselink and have directly the >>> dependency org.eclipse.persistence:eclipselink. On top of that, I don't >>> have the Java EE API dependency. My persistence.xml is fine. >>> >>> What I really want here is when I add a new field Forge to find out >>> that this project has already persistence.xml and not try to rebuild it >>> just because I am missing some dependencies in the pom.xml. >>> >>> Cheers, >>> Ivan >>> >>> On Mon, Jul 6, 2015 at 11:19 PM, George Gastaldi >>> wrote: >>> >>>> Hey Ivan, >>>> >>>> It seems that in your case the JPA 2.0 classes are defined in a >>>> different JAR (a different groupId/artifactId) ? >>>> Your idea might work, however, just make sure that the version >>>> attribute in the persistence.xml defines the installed facet version >>>> (JPAFacet_2_0 when version="2.0" and JPAFacet_2_1 when version="2.1"). >>>> >>>> Best Regards, >>>> George Gastaldi >>>> >>>> >>>> On 07/06/2015 05:13 PM, Ivan St. Ivanov wrote: >>>> >>>> Hi George, >>>> >>>> My idea is the following: if you don't have persistence.xml, then >>>> most probably you don't have the dependencies either. Definitely the facet >>>> is not installed, so Forge installs it for you by adding both the >>>> persistence.xml and the dependencies. >>>> >>>> But if you have persistence.xml already in your project in 99% of the >>>> cases you have already setup the dependencies as well. So the facet is >>>> there and Forge does not need to install it. >>>> >>>> Regards, >>>> Ivan >>>> >>>> On Mon, Jul 6, 2015 at 11:06 PM, George Gastaldi >>>> wrote: >>>> >>>>> Hi Ivan, >>>>> >>>>> I am not sure this is enough. How can you assure that no compilation >>>>> errors would occur when @Entity or any other JPA-related class is used? >>>>> >>>>> Best Regards, >>>>> >>>>> George Gastaldi >>>>> >>>>> >>>>> On 07/06/2015 05:02 PM, Ivan St. Ivanov wrote: >>>>> >>>>> Hi everybody, >>>>> >>>>> I am working on a project that is not mainstream Java EE. Its target >>>>> is Tomcat, but it uses JPA 2.0 (Eclipselink). I have tailored the >>>>> dependencies in the pom.xml as well as the persistence.xml. >>>>> >>>>> And now I want to use Forge to add some fields to the existing >>>>> entities. What I noticed is that when I run the jpa-new-field command for >>>>> the first time, it also installs the JPA facet. Which in turns adds some >>>>> unwanted dependencies to my pom.xml and completely overwrites >>>>> persistence.xml. >>>>> >>>>> I dig into the code and found that the isInstalled method of the JPA >>>>> Facet returns true when persistence.xml file does not exist and when >>>>> pom.xml does not contain some dependencies. These dependencies are >>>>> different for JPA 2.0 and 2.1, but are basically Hibernate JPA API and the >>>>> Java EE API. >>>>> >>>>> As a result of this, projects that don't target Java EE or that use >>>>> different artifacts for it or for JPA are going to get their poms polluted >>>>> and their persistence.xml files overwritten. >>>>> >>>>> So my proposal is to change the isInstalled method to only check for >>>>> the presence of persistence.xml. What do you think? >>>>> >>>>> Regards, >>>>> Ivan >>>>> >>>>> >>>>> _______________________________________________ >>>>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >>>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > _______________________________________________ > forge-dev mailing listforge-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150707/c5809052/attachment-0001.html -------------- next part -------------- _______________________________________________ forge-dev mailing list forge-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev From ggastald at redhat.com Tue Jul 7 10:40:06 2015 From: ggastald at redhat.com (George Gastaldi) Date: Tue, 07 Jul 2015 11:40:06 -0300 Subject: [forge-dev] Forge meeting minutes - 2015-07-07 Message-ID: <559BE4C6.2030306@redhat.com> ============== #forge Meeting ============== Meeting started by gastaldi at 14:00:01 UTC. The full logs are available at http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-07-07-14.00.log.html . Meeting summary --------------- * Agenda (gastaldi, 14:00:22) * Priorities (gastaldi, 14:02:11) * the Website is still a priority. I implemented the change for the addon page, which can be seen in http://forge.jboss.org/addon/org.jboss.forge.addon:wildfly-swarm for example, but the Search fields are still not working (gastaldi, 14:03:13) * As the search feature is the only remaining issue for the Website to fully perform, we'll work on it this week (gastaldi, 14:05:13) * Current Status (gastaldi, 14:05:57) * vineetreynolds is updating the AngularJS addon this week (gastaldi, 14:08:26) * I've been working in the website in the past week, fixing some Roaster bugs and reviewing the GSoC student's work (gastaldi, 14:14:13) * I've been working in the website in the past week, fixing some Roaster bugs and reviewing the GSoC student's work (gastaldi, 14:16:44) * GSoC (gastaldi, 14:22:38) * As I beforementioned, last week I reviewed the GSoC student's work (gastaldi, 14:23:04) * I am proud to say that both passed the midterm evaluation. Looking forward to seeing both completed in the end :) (gastaldi, 14:24:03) * Devanshu is working in the Docker addon and Wicem (addonis1990) is working in the Database Migration addon (gastaldi, 14:24:30) Meeting ended at 14:37:29 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * gastaldi (52) * Devanshu (11) * jbott (10) * vineetreynolds (6) * addonis1990 (3) * jbossbot (2) * lincolnthree (1) * maxandersen (1) * koentsje (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From ggastald at redhat.com Tue Jul 21 11:04:58 2015 From: ggastald at redhat.com (George Gastaldi) Date: Tue, 21 Jul 2015 12:04:58 -0300 Subject: [forge-dev] Forge Meeting minutes - 2015-07-21 Message-ID: <55AE5F9A.6070306@redhat.com> ============== #forge Meeting ============== Meeting started by gastaldi at 14:00:42 UTC. The full logs are available at http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2015/forge.2015-07-21-14.00.log.html . Meeting summary --------------- * Agenda (gastaldi, 14:01:27) * Status reports (gastaldi, 14:04:33) * I've been working on fixing some Forge bugs and helping the Windup team with some ideas this week. The website seems finished (gastaldi, 14:05:12) * The JBoss Forge Spring Boot code retreat is already scheduled for 7-9 August and we already have 12 geeks that subscribed to it! (ivannov, 14:11:40) * reviewed some of your work (lincolnthree, 14:22:07) * helped design the new test extension feature for @deployment-less tests (lincolnthree, 14:22:13) * LINK: https://github.com/forge/core/blob/master/addons/tests/src/test/java/org/jboss/forge/addon/addons/AddonArchiveDefaultSmokeTest.java (gastaldi, 14:25:25) * Priority (gastaldi, 14:42:46) * This week we'll fix some Forge bugs and help contributors (gastaldi, 14:46:00) * Forge is now on GVM (gvmtool.net). Installation instructions: https://gist.github.com/marcoVermeulen/0eefdfcff323f5d3bdcf (gastaldi, 14:47:13) Meeting ended at 15:00:23 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * gastaldi (52) * ivannov (31) * lincolnthree (7) * jbott (6) * jbossbot (2) * vineetreynolds (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From ivan.st.ivanov at gmail.com Sun Jul 26 16:52:19 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Sun, 26 Jul 2015 23:52:19 +0300 Subject: [forge-dev] Approach to Spring Boot handling JPA Message-ID: Hi folks, As some of you probably heard, in Bulgarian JUG we are going to adopt an addon (as George put it a couple of months ago). Beginning of August we are going to develop a Forge extension for Spring Boot. One of the things that we are not sure yet how to tackle is persistence. You see, Spring supports JPA. However instead of configuring it in the Java EE way with persistence.xml, in Spring Boot they use a properties file for that (and for all their configuration). The current JPA facet implementations however are developed with presistence.xml in mind. The JPA setup wizard itself is also bound somehow to presistence.xml - it picks the facet to install based on that file. What we want to do is not to rewrite all the Forge commands for JPA just because of the fact above. We were thinking of a small change - extend JPAFacet with SpringBootJPAFacet. And then add a new implementation of PersistenceContainer -> SpringBootContainer or something? And then we have to change JPASetupWizardImpl to pick the facet not only based on the JPA version, but also based on the container. Or maybe there is a better way? I am expecting your feedback :) Cheers, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150726/17bdf84b/attachment.html From ggastald at redhat.com Mon Jul 27 15:27:52 2015 From: ggastald at redhat.com (George Gastaldi) Date: Mon, 27 Jul 2015 16:27:52 -0300 Subject: [forge-dev] Approach to Spring Boot handling JPA In-Reply-To: References: Message-ID: <55B68638.7020803@redhat.com> Hi Ivan, JPAFacet depends on having a PersistenceCommonDescriptor (https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jboss/forge/addon/javaee/jpa/JPAFacet.java#L27), so I guess that extending JPAFacet is not a good idea in this case. Is it a problem if the persistence.xml is created for a Spring Boot project? Otherwise, I'd suggest you to create the SpringBootJPAFacet without reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as they really don't follow JavaEE in this context beyond the JPA JARs. Best Regards, George Gastaldi On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote: > Hi folks, > > As some of you probably heard, in Bulgarian JUG we are going to adopt > an addon (as George put it a couple of months ago). Beginning of > August we are going to develop a Forge extension for Spring Boot. One > of the things that we are not sure yet how to tackle is persistence. > > You see, Spring supports JPA. However instead of configuring it in the > Java EE way with persistence.xml, in Spring Boot they use a properties > file for that (and for all their configuration). The current JPA facet > implementations however are developed with presistence.xml in mind. > The JPA setup wizard itself is also bound somehow to presistence.xml - > it picks the facet to install based on that file. > > What we want to do is not to rewrite all the Forge commands for JPA > just because of the fact above. We were thinking of a small change - > extend JPAFacet with SpringBootJPAFacet. And then add a new > implementation of PersistenceContainer -> SpringBootContainer or > something? And then we have to change JPASetupWizardImpl to pick the > facet not only based on the JPA version, but also based on the container. > > Or maybe there is a better way? > > I am expecting your feedback :) > > Cheers, > Ivan > > > _______________________________________________ > 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/20150727/17d5c5d6/attachment.html From ivan.st.ivanov at gmail.com Wed Jul 29 13:22:51 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Wed, 29 Jul 2015 20:22:51 +0300 Subject: [forge-dev] Approach to Spring Boot handling JPA In-Reply-To: <55B68638.7020803@redhat.com> References: <55B68638.7020803@redhat.com> Message-ID: Hi George, Thanks for your answer! I add our Spring Boot expert Nayden to the loop. Well, according to the Spring documentation it is possible to have persistence.xml: http://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-access.html#howto-use-traditional-persistence-xml However, I see it more as a hack from our side. Cheers, Ivan On Mon, Jul 27, 2015 at 10:27 PM, George Gastaldi wrote: > Hi Ivan, > > JPAFacet depends on having a PersistenceCommonDescriptor ( > https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jboss/forge/addon/javaee/jpa/JPAFacet.java#L27), > so I guess that extending JPAFacet is not a good idea in this case. Is it a > problem if the persistence.xml is created for a Spring Boot project? > > Otherwise, I'd suggest you to create the SpringBootJPAFacet without > reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as they > really don't follow JavaEE in this context beyond the JPA JARs. > > Best Regards, > > George Gastaldi > > > On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote: > > Hi folks, > > As some of you probably heard, in Bulgarian JUG we are going to adopt an > addon (as George put it a couple of months ago). Beginning of August we are > going to develop a Forge extension for Spring Boot. One of the things that > we are not sure yet how to tackle is persistence. > > You see, Spring supports JPA. However instead of configuring it in the > Java EE way with persistence.xml, in Spring Boot they use a properties file > for that (and for all their configuration). The current JPA facet > implementations however are developed with presistence.xml in mind. The JPA > setup wizard itself is also bound somehow to presistence.xml - it picks the > facet to install based on that file. > > What we want to do is not to rewrite all the Forge commands for JPA just > because of the fact above. We were thinking of a small change - extend > JPAFacet with SpringBootJPAFacet. And then add a new implementation of > PersistenceContainer -> SpringBootContainer or something? And then we have > to change JPASetupWizardImpl to pick the facet not only based on the JPA > version, but also based on the container. > > Or maybe there is a better way? > > I am expecting your feedback :) > > Cheers, > Ivan > > > _______________________________________________ > forge-dev mailing listforge-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150729/bba990eb/attachment.html From gochev at gmail.com Wed Jul 29 16:15:23 2015 From: gochev at gmail.com (Nayden Gochev) Date: Wed, 29 Jul 2015 23:15:23 +0300 Subject: [forge-dev] Approach to Spring Boot handling JPA In-Reply-To: References: <55B68638.7020803@redhat.com> Message-ID: Yes it is a hack (to keep the persistance.xml and is not good :( So we indeed have to create some SpringBootJPAFacet to bypass the generation of persistance.xml and to just add few extra properties to the application.properties file ( basically 5-6 lines ). The idea with spring boot is 0 configuration and everything is automatically configured ( the only configuration you do is in one central properties file) Nayden On Wed, Jul 29, 2015 at 8:22 PM, Ivan St. Ivanov wrote: > Hi George, > > Thanks for your answer! I add our Spring Boot expert Nayden to the loop. > > Well, according to the Spring documentation it is possible to have > persistence.xml: > http://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-access.html#howto-use-traditional-persistence-xml > > However, I see it more as a hack from our side. > > Cheers, > Ivan > > On Mon, Jul 27, 2015 at 10:27 PM, George Gastaldi > wrote: > >> Hi Ivan, >> >> JPAFacet depends on having a PersistenceCommonDescriptor ( >> https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jboss/forge/addon/javaee/jpa/JPAFacet.java#L27), >> so I guess that extending JPAFacet is not a good idea in this case. Is it a >> problem if the persistence.xml is created for a Spring Boot project? >> >> Otherwise, I'd suggest you to create the SpringBootJPAFacet without >> reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as they >> really don't follow JavaEE in this context beyond the JPA JARs. >> >> Best Regards, >> >> George Gastaldi >> >> >> On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote: >> >> Hi folks, >> >> As some of you probably heard, in Bulgarian JUG we are going to adopt >> an addon (as George put it a couple of months ago). Beginning of August we >> are going to develop a Forge extension for Spring Boot. One of the things >> that we are not sure yet how to tackle is persistence. >> >> You see, Spring supports JPA. However instead of configuring it in the >> Java EE way with persistence.xml, in Spring Boot they use a properties file >> for that (and for all their configuration). The current JPA facet >> implementations however are developed with presistence.xml in mind. The JPA >> setup wizard itself is also bound somehow to presistence.xml - it picks the >> facet to install based on that file. >> >> What we want to do is not to rewrite all the Forge commands for JPA >> just because of the fact above. We were thinking of a small change - extend >> JPAFacet with SpringBootJPAFacet. And then add a new implementation of >> PersistenceContainer -> SpringBootContainer or something? And then we have >> to change JPASetupWizardImpl to pick the facet not only based on the JPA >> version, but also based on the container. >> >> Or maybe there is a better way? >> >> I am expecting your feedback :) >> >> Cheers, >> Ivan >> >> >> _______________________________________________ >> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150729/2458241c/attachment-0001.html From ggastald at redhat.com Wed Jul 29 16:31:52 2015 From: ggastald at redhat.com (George Gastaldi) Date: Wed, 29 Jul 2015 16:31:52 -0400 (EDT) Subject: [forge-dev] Approach to Spring Boot handling JPA In-Reply-To: References: <55B68638.7020803@redhat.com> Message-ID: How about a SpringBootFacet with a ge/setProperties() method to handle these central properties?? As for the JPAFacet, it is necessary to have it installed for the JPA: New Entity to function properly, for example, so I guess you might need to extend it and override the method that creates the persistence.xml file.?
-------- Mensagem original --------
De: Nayden Gochev
Data: 29/07/2015 17:21 (GMT-03:00)
Para: "Ivan St. Ivanov"
Cc: forge-dev List
Assunto: Re: [forge-dev] Approach to Spring Boot handling JPA
Yes it is a hack (to keep the persistance.xml and is not good :( So we indeed have to create some SpringBootJPAFacet to bypass the generation of persistance.xml and to just add few extra properties to the application.properties file ( basically 5-6 lines ). The idea with spring boot is 0 configuration and everything is automatically configured ( the only configuration you do is in one central properties file) Nayden On Wed, Jul 29, 2015 at 8:22 PM, Ivan St. Ivanov wrote: > Hi George, > > Thanks for your answer! I add our Spring Boot expert Nayden to the loop. > > Well, according to the Spring documentation it is possible to have > persistence.xml: > http://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-access.html#howto-use-traditional-persistence-xml > > However, I see it more as a hack from our side. > > Cheers, > Ivan > > On Mon, Jul 27, 2015 at 10:27 PM, George Gastaldi > wrote: > >> Hi Ivan, >> >> JPAFacet depends on having a PersistenceCommonDescriptor ( >> https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jboss/forge/addon/javaee/jpa/JPAFacet.java#L27), >> so I guess that extending JPAFacet is not a good idea in this case. Is it a >> problem if the persistence.xml is created for a Spring Boot project? >> >> Otherwise, I'd suggest you to create the SpringBootJPAFacet without >> reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as they >> really don't follow JavaEE in this context beyond the JPA JARs. >> >> Best Regards, >> >> George Gastaldi >> >> >> On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote: >> >> Hi folks, >> >> As some of you probably heard, in Bulgarian JUG we are going to adopt >> an addon (as George put it a couple of months ago). Beginning of August we >> are going to develop a Forge extension for Spring Boot. One of the things >> that we are not sure yet how to tackle is persistence. >> >> You see, Spring supports JPA. However instead of configuring it in the >> Java EE way with persistence.xml, in Spring Boot they use a properties file >> for that (and for all their configuration). The current JPA facet >> implementations however are developed with presistence.xml in mind. The JPA >> setup wizard itself is also bound somehow to presistence.xml - it picks the >> facet to install based on that file. >> >> What we want to do is not to rewrite all the Forge commands for JPA >> just because of the fact above. We were thinking of a small change - extend >> JPAFacet with SpringBootJPAFacet. And then add a new implementation of >> PersistenceContainer -> SpringBootContainer or something? And then we have >> to change JPASetupWizardImpl to pick the facet not only based on the JPA >> version, but also based on the container. >> >> Or maybe there is a better way? >> >> I am expecting your feedback :) >> >> Cheers, >> Ivan >> >> >> _______________________________________________ >> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150729/8d1b94cc/attachment.html -------------- next part -------------- _______________________________________________ forge-dev mailing list forge-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev From ivan.st.ivanov at gmail.com Thu Jul 30 03:22:26 2015 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Thu, 30 Jul 2015 10:22:26 +0300 Subject: [forge-dev] Approach to Spring Boot handling JPA In-Reply-To: References: <55B68638.7020803@redhat.com> Message-ID: Hi George, Then maybe we should re-evaluate the initial proposal: What we want to do is not to rewrite all the Forge commands for JPA just because of the fact above. We were thinking of a small change - extend JPAFacet with SpringBootJPAFacet. And then add a new implementation of PersistenceContainer -> SpringBootContainer or something? And then we have to change JPASetupWizardImpl to pick the facet not only based on the JPA version, but also based on the container. Thanks, Ivan On Wed, Jul 29, 2015 at 11:31 PM, George Gastaldi wrote: > How about a SpringBootFacet with a ge/setProperties() method to handle > these central properties? > > As for the JPAFacet, it is necessary to have it installed for the JPA: New > Entity to function properly, for example, so I guess you might need to > extend it and override the method that creates the persistence.xml file. > > > -------- Mensagem original -------- > De: Nayden Gochev > Data: 29/07/2015 17:21 (GMT-03:00) > Para: "Ivan St. Ivanov" > Cc: forge-dev List > Assunto: Re: [forge-dev] Approach to Spring Boot handling JPA > > > Yes it is a hack (to keep the persistance.xml and is not good :( > > So we indeed have to create some SpringBootJPAFacet to bypass the > generation of persistance.xml and to just add few extra properties to the > application.properties file ( basically 5-6 lines ). > > The idea with spring boot is 0 configuration and everything is > automatically configured ( the only configuration you do is in one central > properties file) > > Nayden > > On Wed, Jul 29, 2015 at 8:22 PM, Ivan St. Ivanov > wrote: > >> Hi George, >> >> Thanks for your answer! I add our Spring Boot expert Nayden to the loop. >> >> Well, according to the Spring documentation it is possible to have >> persistence.xml: >> http://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-access.html#howto-use-traditional-persistence-xml >> >> However, I see it more as a hack from our side. >> >> Cheers, >> Ivan >> >> On Mon, Jul 27, 2015 at 10:27 PM, George Gastaldi >> wrote: >> >>> Hi Ivan, >>> >>> JPAFacet depends on having a PersistenceCommonDescriptor ( >>> https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jboss/forge/addon/javaee/jpa/JPAFacet.java#L27), >>> so I guess that extending JPAFacet is not a good idea in this case. Is it a >>> problem if the persistence.xml is created for a Spring Boot project? >>> >>> Otherwise, I'd suggest you to create the SpringBootJPAFacet without >>> reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as they >>> really don't follow JavaEE in this context beyond the JPA JARs. >>> >>> Best Regards, >>> >>> George Gastaldi >>> >>> >>> On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote: >>> >>> Hi folks, >>> >>> As some of you probably heard, in Bulgarian JUG we are going to adopt an >>> addon (as George put it a couple of months ago). Beginning of August we are >>> going to develop a Forge extension for Spring Boot. One of the things that >>> we are not sure yet how to tackle is persistence. >>> >>> You see, Spring supports JPA. However instead of configuring it in the >>> Java EE way with persistence.xml, in Spring Boot they use a properties file >>> for that (and for all their configuration). The current JPA facet >>> implementations however are developed with presistence.xml in mind. The JPA >>> setup wizard itself is also bound somehow to presistence.xml - it picks the >>> facet to install based on that file. >>> >>> What we want to do is not to rewrite all the Forge commands for JPA just >>> because of the fact above. We were thinking of a small change - extend >>> JPAFacet with SpringBootJPAFacet. And then add a new implementation of >>> PersistenceContainer -> SpringBootContainer or something? And then we have >>> to change JPASetupWizardImpl to pick the facet not only based on the JPA >>> version, but also based on the container. >>> >>> Or maybe there is a better way? >>> >>> I am expecting your feedback :) >>> >>> Cheers, >>> Ivan >>> >>> >>> _______________________________________________ >>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20150730/4f3e84bd/attachment.html