Re: [forge-dev] JPA setup command question

Try doing project.getFacet(MavenFacet.class).getModel() and you should have the pom.xml model available Em 27/11/2014, às 19:28, Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com&gt; escreveu: So I was preparing the test. I wanted to create a test case that prints the content of the pom.xml after it invokes the setup command. Here is how I prepare everything: @Inject private UITestHarness testHarness; @Inject private ProjectFactory projectFactory; @Inject private EclipseLinkProvider provider; @Inject private WildflyContainer wildflyContainer; @Test public void testPomXmlContent() throws Exception { Project project = projectFactory.createTempProject(); WizardCommandController tester = testHarness.createWizardController(JPASetupWizard.class, project.getRoot()); tester.initialize(); // Setting UI values tester.setValueFor("jpaVersion", "2.1"); tester.setValueFor("provider", provider); tester.setValueFor("container", wildflyContainer); tester.next().initialize(); Assert.assertTrue(tester.isValid()); tester.execute(); } And now I want to somehow get the dependency facet or some other facet and print the content of pom.xml (or the dependencies). How can I do that? Thanks, Ivan On Wed, Nov 26, 2014 at 10:56 AM, Ivan St. Ivanov < ivan.st.ivanov(a)gmail.com&gt; wrote: > Hi George, > > I can work on providing those tests and crafting a solution for the case > when the JPA provider is not packed with the target container. Will jump in > the IRC channel this week and discuss in more details with you. > > I see that the JavaEEDefaultContainer implements methods that imply JTA > data source. No matter that SAP HCP is built on top of Tomcat, we have our > own persistence service, which provides JTA data source. So, generally you > are right that I should not extend that abstract class, but in this > concrete case with HANA Cloud Platform it is the right thing to do. > > Cheers, > Ivan > > On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald(a)redhat.com&gt; > wrote: > >> Right, I think this makes sense. We might need to add more tests under >> these conditions. This area sure needs a bit of improvement. >> >> It looks like SAPHanaCloudPlatformContainer shouldn't be extending >> JavaEEDefaultContainer, afaik that is only meant to be extended by >> implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic, >> GlassFish). >> >> On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote: >> >> Hi George, >> >> I was thinking of something general in the area of tying up >> somehow (not coupling) the JPA containers and providers. The containers >> know very well whether they have JPA support at all or, if they have, what >> is their native provider (e.g. Hibernate for Wildfly). So IMHO whenever the >> user specifies a container with a provider the setup command should do the >> following: >> >> 1) Validate whether this combination is possible at all (e.g. not sure >> what will happen if we specify Wildfly with EclipseLink, at the moment it >> fails) >> 2) If the current container does not have built-in support for JPA (i.e. >> it is based on Tomcat, like SAP HCP) or it supports natively different JPA >> provider, then add the listDependencies() content to the pom.xml in the >> appropriate scope >> >> Something like this. Not sure though how was this whole thing intended >> to work: do we need to fully decouple providers and containers in the JPA >> addon? >> >> Cheers, >> Ivan >> >> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald(a)redhat.com&gt; >> wrote: >> >>> Hi Ivan, >>> >>> Yes, that's the idea. It's strange that this method is not being >>> called. I'll investigate further. >>> >>> Another solution would be to create a new Forge's PersistenceProvider >>> implementation in a separate addon and select that instead when running >>> Jpa:Setup. >>> >>> Best Regards, >>> >>> George Gastaldi >>> >>> >>> > Em 24/11/2014, às 08:25, Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com&gt; >>> escreveu: >>> > >>> > Hi everybody, >>> > >>> > I have the following usecase. I am developing a web application that >>> uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform >>> (think of it as Tomcat). Which means that I need the Eclipse Link >>> dependencies in the pom.xml in the compile scope. When I generated the >>> project and set up Eclipse Link, I got this in the pom: >>> > >>> > <dependencies> >>> > <dependency> >>> > <groupId>org.hibernate.javax.persistence</groupId> >>> > <artifactId>hibernate-jpa-2.0-api</artifactId> >>> > <scope>provided</scope> >>> > </dependency> >>> > </dependencies> >>> > >>> > However, I rather need something like: >>> > >>> > <dependency> >>> > <groupId>org.eclipse.persistence</groupId> >>> > <artifactId>javax.persistence</artifactId> >>> > </dependency> >>> > <dependency> >>> > <groupId>org.eclipse.persistence</groupId> >>> > <artifactId>eclipselink</artifactId> >>> > </dependency> >>> > >>> > I see in >>> org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider: >>> > >>> > >>> > @Override >>> > public List<Dependency> listDependencies() >>> > { >>> > return Arrays.asList((Dependency) >>> DependencyBuilder.create("org.eclipse.persistence:eclipselink"), >>> > (Dependency) >>> DependencyBuilder.create("org.eclipse.persistence:javax.persistence")); >>> > } >>> > >>> > So we already have functionality on provider level that knows which >>> are the dependencies. However, it seems that this method is not called. >>> What was the idea of having it? How can I make sure that the dependencies >>> are correctly configured? >>> > >>> > I think that it has something to do with the type of the container: >>> if it is SAP HANA Cloud Platform, then find the dependencies for the JPA >>> provider and add them in the default scope of the pom.xml instead of adding >>> hibernate-jpa-2.0-api. If it is a full fledged application server, then we >>> can go with the API in provided scope. Something like this. >>> > >>> > WDYT? >>> > >>> > Thanks, >>> > Ivan >>> > _______________________________________________ >>> > forge-dev mailing list >>> > forge-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/forge-dev >>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> >> _______________________________________________ >> forge-dev mailing listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev