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 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
>>
>> <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