[forge-dev] JPA setup command question
Ivan St. Ivanov
ivan.st.ivanov at gmail.com
Fri Nov 28 07:38:16 EST 2014
I don't have any experience with Drools or rules engines per se. I may try
to hack something and based on that we can think whether it is worth the
effort. OK?
On Fri, Nov 28, 2014 at 2:34 PM, George Gastaldi <ggastald at redhat.com>
wrote:
> Yes, I agree.
>
> However I wonder if these combinations wouldn't become too hard to
> maintain? This looks like something that could be implemented using a rule
> engine, like Drools.
>
> Thoughts?
>
>
> Em 28/11/2014, às 07:37, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
> escreveu:
>
> Hi George,
>
> This sounds a bit complex :)
>
> In summary we have the following three situations:
>
> 1) Application server type of container + primary JPA provider, e.g.
> Wildfly + Hibernate JPA
> 2) Application server type of container + other JPA provider, e.g.Wildfly
> + Eclipselink
> 3) Non application server type of container, i.e. application has to come
> packaged with the JPA libraries, e.g. Tomcat
>
> At the moment Forge supports 1). Adding support for 3) would not be very
> hard I think. However we should handle 2) case by case I guess. I think
> that we definitely need an abstraction in the JPA commands that knows how
> to deal with the container+provider combinations.
>
> WDYT?
>
> Cheers,
> Ivan
>
> On Fri, Nov 28, 2014 at 1:57 AM, George Gastaldi <ggastald at redhat.com>
> wrote:
>
>> I think this involves doing what's defined in
>> https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide
>> We should be able to do the necessary changes in the project, however I
>> think we may need to point users to this documentation to handle the
>> changes in the AS itself (or ask Forge to do that itself)
>>
>>
>>
>> Em 27/11/2014, às 19:58, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>> escreveu:
>>
>> 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
>>>
>>
>> <JPASetupDifferentProviderTest.java>
>>
>> _______________________________________________
>> 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/20141128/30573110/attachment-0001.html
More information about the forge-dev
mailing list