[forge-dev] JPA setup command question

[ivan_stefanov]

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:

   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

[gastaldi]

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 <[e-mail]> 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

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[ivan_stefanov]

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 <[e-mail]>

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 <[e-mail]>

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

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[gastaldi]

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 <[e-mail]

<mailto:[e-mail]>> 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

    <[e-mail] <mailto:[e-mail]>> 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

    > [e-mail] <mailto:[e-mail]>

    > https://lists.jboss.org/mailman/listinfo/forge-dev

    _______________________________________________

    forge-dev mailing list

    [e-mail] <mailto:[e-mail]>

    https://lists.jboss.org/mailman/listinfo/forge-dev

>

>

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[ivan_stefanov]

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 <[e-mail]>

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 <[e-mail]>

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  https://lists.jboss.org/mailman/listinfo/forge-dev

>

>

_______________________________________________

forge-dev mailing [e-mail]://lists.jboss.org/mailman/listinfo/forge-dev

>

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[ivan_stefanov]

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 <[e-mail]>

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 <[e-mail]>

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

[gastaldi]

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 <[e-mail]> 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  https://lists.jboss.org/mailman/listinfo/forge-dev

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[ivan_stefanov]

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 <[e-mail]>

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 <[e-mail]>

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 <

[e-mail]> 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 

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

>

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[gastaldi]

I think this involves doing what's defined in https://docs.jboss.org/author/display/WFLY8/JPAReferenceGuide

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 <[e-mail]> 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  https://lists.jboss.org/mailman/listinfo/forge-dev

<JPASetupDifferentProviderTest.java>

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[ivan_stefanov]

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 <[e-mail]>

wrote:

I think this involves doing what's defined in

https://docs.jboss.org/author/display/WFLY8/JPAReferenceGuide

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 <[e-mail]>

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 <[e-mail]>

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

<JPASetupDifferentProviderTest.java>

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

>

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[gastaldi]

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 <[e-mail]> 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 <[e-mail]> wrote:

>> I think this involves doing what's defined in https://docs.jboss.org/author/display/WFLY8/JPAReferenceGuide

>> 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  https://lists.jboss.org/mailman/listinfo/forge-dev

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[ivan_stefanov]

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 <[e-mail]>

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 <[e-mail]>

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 <[e-mail]>

wrote:

>> I think this involves doing what's defined in

>> https://docs.jboss.org/author/display/WFLY8/JPAReferenceGuide

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

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

>

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[gastaldi]

Sounds good

Em 28/11/2014, às 10:38, Ivan St. Ivanov <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:

>>>> I think this involves doing what's defined in https://docs.jboss.org/author/display/WFLY8/JPAReferenceGuide

>>>> 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  https://lists.jboss.org/mailman/listinfo/forge-dev

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[ivan_stefanov]

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 <[e-mail]>

wrote:

Sounds good

>

Em 28/11/2014, às 10:38, Ivan St. Ivanov <[e-mail]>

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 <[e-mail]>

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 <[e-mail]>

>> 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 <[e-mail]>

>> wrote:

>>

>>> I think this involves doing what's defined in

>>> https://docs.jboss.org/author/display/WFLY8/JPAReferenceGuide

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

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

>

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[gastaldi]

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 <[e-mail]> 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 <[e-mail]> wrote:

>> Sounds good

>>

>>

>>

>>> Em 28/11/2014, às 10:38, Ivan St. Ivanov <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:

>>>>>> I think this involves doing what's defined in https://docs.jboss.org/author/display/WFLY8/JPAReferenceGuide

>>>>>> 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  https://lists.jboss.org/mailman/listinfo/forge-dev

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev