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:
Cheers,
Ivan
On Fri, Nov 28, 2014 at 2:48 PM, George Gastaldi <ggastald(a)redhat.com>
wrote:
Sounds good
Em 28/11/2014, às 10:38, Ivan St. Ivanov <ivan.st.ivanov(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(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
>>>
>>
>> <JPASetupDifferentProviderTest.java>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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