[forge-dev] JPA setup command question
Ivan St. Ivanov
ivan.st.ivanov at gmail.com
Sun Nov 30 16:00:03 EST 2014
Hi George,
Today I went through the Drools documentation. I am afraid that it could be
overkill, but anyway, I posted a question to the Drools ML:
https://groups.google.com/forum/#!topic/drools-usage/VHqb-BZZiBI
Cheers,
Ivan
On Fri, Nov 28, 2014 at 2:48 PM, George Gastaldi <ggastald at redhat.com>
wrote:
> Sounds good
>
>
>
> Em 28/11/2014, às 10:38, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
> escreveu:
>
> 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
>>
>
> _______________________________________________
> 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/20141130/9cd54cb9/attachment-0001.html
More information about the forge-dev
mailing list