11:25 a.m.
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
12:11 p.m.
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
1:39 p.m.
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
2:26 p.m.
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
<mailto:ggastald@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 <mailto:ivan.st.ivanov@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 <mailto:forge-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org <mailto:forge-dev@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
9:56 a.m.
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
10:28 p.m.
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
>
10:35 p.m.
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
10:57 p.m.
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
12:57 a.m.
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
10:36 a.m.
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
1:34 p.m.
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
1:38 p.m.
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
1:48 p.m.
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 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
>
> _______________________________________________
> 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
10 p.m.
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(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
10:12 p.m.
Right, I am not saying we should follow this strategy, it's just an idea.
Em 30/11/2014, às 19:00, Ivan St. Ivanov
<ivan.st.ivanov(a)gmail.com> escreveu:
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(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 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
>>>
>>> _______________________________________________
>>> 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
3428
days inactive
3434
days old
14 comments
2 participants
participants (2)
-
George Gastaldi -
Ivan St. Ivanov