[forge-dev] JPA setup command question

Ivan St. Ivanov ivan.st.ivanov at gmail.com
Thu Nov 27 16:28:42 EST 2014


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 at gmail.com>
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 at redhat.com>
> 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 at redhat.com>
>> 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 at gmail.com>
>>> 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 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/20141127/d5185c1b/attachment.html 


More information about the forge-dev mailing list