[forge-dev] JPA setup command question

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


Thanks George!

So I have attached the test. You can put it in the javaee addon, under the
test folder. It's located in the org.jboss.forge.addon.javaee.jpa.ui.setup
package. After you run it, look for the 'dependencies = ' string in the
output. I've set it up to use EclipseLink on Wildfly container. I suppose
it is not going to work with the JPA API dependency only, is it?

Cheers,
Ivan

On Thu, Nov 27, 2014 at 11:35 PM, George Gastaldi <ggastald at redhat.com>
wrote:

> 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 at gmail.com>
> 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 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
>>>
>>
>>
> _______________________________________________
> 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/20141127/bbc217f9/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JPASetupDifferentProviderTest.java
Type: text/x-java
Size: 3555 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/forge-dev/attachments/20141127/bbc217f9/attachment-0001.bin 


More information about the forge-dev mailing list