From antonio.mailing at gmail.com  Tue Nov  4 04:24:23 2014
From: antonio.mailing at gmail.com (Antonio Goncalves)
Date: Tue, 4 Nov 2014 10:24:23 +0100
Subject: [forge-dev]  Releasing 2.12.2.Final earlier ?
Message-ID: <CAKawoObc9FG4Azs3ACGzf-4=hKQfU7_xSV5zBo8VqG_KBvENSg@mail.gmail.com>

Hi all,

As you might know, we will be at Devoxx BE next week doing a three hours
hands on lab. I'll be mostly doing the script part, and I just sent a PR
that will help me (https://issues.jboss.org/browse/FORGE-2101).

Do you think you could release the 2.12.2 earlier so I can benefit from
this improvement ? Somewhere around next Thursday/Friday would be perfect.

Thanks

-- 
Antonio Goncalves
Software architect and Java Champion

Web site <http://www.antoniogoncalves.org/> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>
 | Paris JUG <http://www.parisjug.org/> | Devoxx France
<http://www.devoxx.fr/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141104/8be588e6/attachment-0001.html 

From ggastald at redhat.com  Tue Nov  4 08:01:54 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Tue, 4 Nov 2014 08:01:54 -0500 (EST)
Subject: [forge-dev] Releasing 2.12.2.Final earlier ?
In-Reply-To: <CAKawoObc9FG4Azs3ACGzf-4=hKQfU7_xSV5zBo8VqG_KBvENSg@mail.gmail.com>
References: <CAKawoObc9FG4Azs3ACGzf-4=hKQfU7_xSV5zBo8VqG_KBvENSg@mail.gmail.com>
Message-ID: <5F153E15-1298-4A25-92AF-9479B9F1A61B@redhat.com>

Definitely,we can shoot for this Friday, no problem on that. 

However it's important to mention that the Forge version in JDBS will remain 2.12.1.Final, because their release cycle is different from ours. After the release I'll submit a PR to the JBDS team but we'll have to wait for the Jboss Tools team to include it in the next JBDS release.  We could ask users to upgrade by pointing to the nightly update site, but I am not 100% sure that it will work in JBDS (this is a good opportunity to test it).



> Em 04/11/2014, ?s 07:24, Antonio Goncalves <antonio.mailing at gmail.com> escreveu:
> 
> Hi all,
> 
> As you might know, we will be at Devoxx BE next week doing a three hours hands on lab. I'll be mostly doing the script part, and I just sent a PR that will help me (https://issues.jboss.org/browse/FORGE-2101).
> 
> Do you think you could release the 2.12.2 earlier so I can benefit from this improvement ? Somewhere around next Thursday/Friday would be perfect.
> 
> Thanks
> 
> -- 
> Antonio Goncalves 
> Software architect and Java Champion
> 
> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141104/232adfa5/attachment.html 

From antonio.mailing at gmail.com  Tue Nov  4 08:39:28 2014
From: antonio.mailing at gmail.com (Antonio Goncalves)
Date: Tue, 4 Nov 2014 14:39:28 +0100
Subject: [forge-dev] Releasing 2.12.2.Final earlier ?
In-Reply-To: <5F153E15-1298-4A25-92AF-9479B9F1A61B@redhat.com>
References: <CAKawoObc9FG4Azs3ACGzf-4=hKQfU7_xSV5zBo8VqG_KBvENSg@mail.gmail.com>
	<5F153E15-1298-4A25-92AF-9479B9F1A61B@redhat.com>
Message-ID: <CAKawoOb8zJn4EKaEd9v9ZOuHedTD3a-XRkgpv7F6Z3Vzzdj2LA@mail.gmail.com>

That's fine because it's just to execute a script, no need to have JBDS on
the latest release of Forge

2014-11-04 14:01 GMT+01:00 George Gastaldi <ggastald at redhat.com>:

> Definitely,we can shoot for this Friday, no problem on that.
>
> However it's important to mention that the Forge version in JDBS will
> remain 2.12.1.Final, because their release cycle is different from ours.
> After the release I'll submit a PR to the JBDS team but we'll have to wait
> for the Jboss Tools team to include it in the next JBDS release.  We could
> ask users to upgrade by pointing to the nightly update site, but I am not
> 100% sure that it will work in JBDS (this is a good opportunity to test it).
>
>
>
> Em 04/11/2014, ?s 07:24, Antonio Goncalves <antonio.mailing at gmail.com>
> escreveu:
>
> Hi all,
>
> As you might know, we will be at Devoxx BE next week doing a three hours
> hands on lab. I'll be mostly doing the script part, and I just sent a PR
> that will help me (https://issues.jboss.org/browse/FORGE-2101).
>
> Do you think you could release the 2.12.2 earlier so I can benefit from
> this improvement ? Somewhere around next Thursday/Friday would be perfect.
>
> Thanks
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org/> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG
> <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Antonio Goncalves
Software architect and Java Champion

Web site <http://www.antoniogoncalves.org/> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>
 | Paris JUG <http://www.parisjug.org/> | Devoxx France
<http://www.devoxx.fr/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141104/93372806/attachment.html 

From ivan.st.ivanov at gmail.com  Tue Nov  4 08:54:40 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Tue, 4 Nov 2014 15:54:40 +0200
Subject: [forge-dev] Releasing 2.12.2.Final earlier ?
In-Reply-To: <CAKawoOb8zJn4EKaEd9v9ZOuHedTD3a-XRkgpv7F6Z3Vzzdj2LA@mail.gmail.com>
References: <CAKawoObc9FG4Azs3ACGzf-4=hKQfU7_xSV5zBo8VqG_KBvENSg@mail.gmail.com>
	<5F153E15-1298-4A25-92AF-9479B9F1A61B@redhat.com>
	<CAKawoOb8zJn4EKaEd9v9ZOuHedTD3a-XRkgpv7F6Z3Vzzdj2LA@mail.gmail.com>
Message-ID: <CACYLA9E5yAHm_1=MUq7FOFCDyXB_xkB8DXOKUnKntJKJ_rAT0A@mail.gmail.com>

So besides JBDS, the attendees will have to download the CLI as well. Even
those that will do the HoL in the IDE.

On Tue, Nov 4, 2014 at 3:39 PM, Antonio Goncalves <antonio.mailing at gmail.com
> wrote:

> That's fine because it's just to execute a script, no need to have JBDS on
> the latest release of Forge
>
> 2014-11-04 14:01 GMT+01:00 George Gastaldi <ggastald at redhat.com>:
>
>> Definitely,we can shoot for this Friday, no problem on that.
>>
>> However it's important to mention that the Forge version in JDBS will
>> remain 2.12.1.Final, because their release cycle is different from ours.
>> After the release I'll submit a PR to the JBDS team but we'll have to wait
>> for the Jboss Tools team to include it in the next JBDS release.  We could
>> ask users to upgrade by pointing to the nightly update site, but I am not
>> 100% sure that it will work in JBDS (this is a good opportunity to test it).
>>
>>
>>
>> Em 04/11/2014, ?s 07:24, Antonio Goncalves <antonio.mailing at gmail.com>
>> escreveu:
>>
>> Hi all,
>>
>> As you might know, we will be at Devoxx BE next week doing a three hours
>> hands on lab. I'll be mostly doing the script part, and I just sent a PR
>> that will help me (https://issues.jboss.org/browse/FORGE-2101).
>>
>> Do you think you could release the 2.12.2 earlier so I can benefit from
>> this improvement ? Somewhere around next Thursday/Friday would be perfect.
>>
>> Thanks
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>
>> Web site <http://www.antoniogoncalves.org/> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>> <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org/> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG
> <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141104/9b705b42/attachment.html 

From lincolnbaxter at gmail.com  Tue Nov  4 09:16:41 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Tue, 4 Nov 2014 09:16:41 -0500
Subject: [forge-dev] Releasing 2.12.2.Final earlier ?
In-Reply-To: <CACYLA9E5yAHm_1=MUq7FOFCDyXB_xkB8DXOKUnKntJKJ_rAT0A@mail.gmail.com>
References: <CAKawoObc9FG4Azs3ACGzf-4=hKQfU7_xSV5zBo8VqG_KBvENSg@mail.gmail.com>
	<5F153E15-1298-4A25-92AF-9479B9F1A61B@redhat.com>
	<CAKawoOb8zJn4EKaEd9v9ZOuHedTD3a-XRkgpv7F6Z3Vzzdj2LA@mail.gmail.com>
	<CACYLA9E5yAHm_1=MUq7FOFCDyXB_xkB8DXOKUnKntJKJ_rAT0A@mail.gmail.com>
Message-ID: <CAEp_U4GLZc2E5d7zuq8MxvNQ9a8bX3aSS37Qhh9d4vxbBHvHog@mail.gmail.com>

Okay, yes, we can definitely do an early release. That's no problem.

On Tue, Nov 4, 2014 at 8:54 AM, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
wrote:

> So besides JBDS, the attendees will have to download the CLI as well. Even
> those that will do the HoL in the IDE.
>
> On Tue, Nov 4, 2014 at 3:39 PM, Antonio Goncalves <
> antonio.mailing at gmail.com> wrote:
>
>> That's fine because it's just to execute a script, no need to have JBDS
>> on the latest release of Forge
>>
>> 2014-11-04 14:01 GMT+01:00 George Gastaldi <ggastald at redhat.com>:
>>
>>> Definitely,we can shoot for this Friday, no problem on that.
>>>
>>> However it's important to mention that the Forge version in JDBS will
>>> remain 2.12.1.Final, because their release cycle is different from ours.
>>> After the release I'll submit a PR to the JBDS team but we'll have to wait
>>> for the Jboss Tools team to include it in the next JBDS release.  We could
>>> ask users to upgrade by pointing to the nightly update site, but I am not
>>> 100% sure that it will work in JBDS (this is a good opportunity to test it).
>>>
>>>
>>>
>>> Em 04/11/2014, ?s 07:24, Antonio Goncalves <antonio.mailing at gmail.com>
>>> escreveu:
>>>
>>> Hi all,
>>>
>>> As you might know, we will be at Devoxx BE next week doing a three hours
>>> hands on lab. I'll be mostly doing the script part, and I just sent a PR
>>> that will help me (https://issues.jboss.org/browse/FORGE-2101).
>>>
>>> Do you think you could release the 2.12.2 earlier so I can benefit from
>>> this improvement ? Somewhere around next Thursday/Friday would be perfect.
>>>
>>> Thanks
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect and Java Champion
>>>
>>> Web site <http://www.antoniogoncalves.org/> | Twitter
>>> <http://twitter.com/agoncal> | LinkedIn
>>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>>> <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>
>> Web site <http://www.antoniogoncalves.org/> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>> <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141104/7acd11fa/attachment-0001.html 

From lincolnbaxter at gmail.com  Wed Nov  5 11:51:35 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 5 Nov 2014 11:51:35 -0500
Subject: [forge-dev] Forge Meeting Minutes - 2014-11-05
Message-ID: <CAEp_U4GXGKkY7gyvP8qGOm4ByBEfV4hbZ5OQFcsu4eY5srYB2g@mail.gmail.com>

Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2014/forge.2014-11-05-16.04.html

Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2014/forge.2014-11-05-16.04.txt

Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2014/forge.2014-11-05-16.04.log.html

Meeting summary
---------------
* Agenda  (lincolnthree, 16:04:43)

* Status Reports  (lincolnthree, 16:07:31)
  * I have no status to report other than a few housekeeping tasks and
    meeting with some partners to discuss using Forge  (lincolnthree,
    16:08:02)
  * I am working on the NetBeans Plugin integration. URL is private in
    https://bitbucket.org/gastaldi/netbeans-plugin/  (gastaldi,
    16:08:26)
  * Had another talk yesterday on CDI using Forge, and still working on
    the HoL  (agoncal, 16:09:02)
  * Next Forge release will take place on Nov, 7th  (gastaldi, 16:10:15)
  * I also began to review the Hands On Lab  (lincolnthree, 16:10:24)
  * I reviewed the Hands On Lab and pushed some minor fixes to the docs
    (gastaldi, 16:10:54)

* Hands On Lab Status  (lincolnthree, 16:19:07)

* Hol  (gastaldi, 16:46:38)

* Website Status  (gastaldi, 16:48:04)
  * still waiting on more designs and approval to continue implementing
    (lincolnthree, 16:49:54)

-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141105/7697c4ba/attachment.html 

From antonio.goncalves at gmail.com  Tue Nov 11 07:33:25 2014
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Tue, 11 Nov 2014 13:33:25 +0100
Subject: [forge-dev] Funny exception in generating rest endoint
Message-ID: <CA+ZZq9_dAjUnasknSDFuz=7CcPya3K7nTyiqouFU+_p6=1RfBw@mail.gmail.com>

Hi

During the HoL one guy had this problem (on windows) generating REST
endpoints. The generated code is ok, and everything works fine, but here is
the stack trace


---------- Forwarded message ----------
From: Ilya Masharov <ilya.masharov at gmail.com>
Date: 2014-11-11 10:30 GMT+01:00
Subject: Forge stacktrace
To: antonio.goncalves at gmail.com



11:29:22,655 SEVERE
[org.jboss.forge.addon.ui.impl.controller.AbstractCommandController]
(AeshProcess: 45) Error while notifying listeners:
java.lang.ClassCastException: java.util.ArrayList cannot be cast to
org.jboss.forge.addon.resource.FileResource

at
org.jboss.forge.addon.projects.Projects.getSelectedProject(Projects.java:37)

at
org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener.postCommandExecuted(ProjectBuildStatusListener.java:41)

at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source) [:1.8.0_05]

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_05]

at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_05]

at
org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:87)
[furnace-proxy-2.10.1.Final.jar:2.10.1.Final]

at
org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:42)
[furnace-api-2.10.1.Final.jar:2.10.1.Final]

at
org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:103)
[furnace-proxy-2.10.1.Final.jar:2.10.1.Final]

at
org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.postCommandExecuted(ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.java)

at
org.jboss.forge.addon.ui.impl.controller.AbstractCommandController.firePostCommandExecuted(AbstractCommandController.java:144)
[ui-impl-2.10.1.Final.jar:2.10.1.Final]

at
org.jboss.forge.addon.ui.impl.controller.SingleCommandControllerImpl.execute(SingleCommandControllerImpl.java:89)
[ui-impl-2.10.1.Final.jar:2.10.1.Final]

at
org.jboss.forge.addon.shell.aesh.CommandAdapter.execute(CommandAdapter.java:74)
[shell-impl-2.10.1.Final.jar:2.10.1.Final]

at
org.jboss.aesh.console.AeshConsoleImpl$AeshConsoleCallbackImpl.execute(AeshConsoleImpl.java:325)
[aesh-0.56.1.jar:0.56.1]

at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:40)
[aesh-0.56.1.jar:0.56.1]

at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_05]

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_05]

at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]



--
Antonio Goncalves (antonio.goncalves at gmail.com)
Software architect

Web site : www.antoniogoncalves.org
Blog: agoncal.wordpress.com
Feed: feeds2.feedburner.com/AntonioGoncalves
Paris JUG leader : www.parisjug.org
LinkedIn: www.linkedin.com/in/agoncal

_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141111/11da2942/attachment-0001.html 

From antonio.goncalves at gmail.com  Tue Nov 11 07:34:33 2014
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Tue, 11 Nov 2014 13:34:33 +0100
Subject: [forge-dev] PermGen with JBoss add-on
Message-ID: <CA+ZZq9_92kmVLoGN+yxJjuc4c8434XFjSWKwo951NRnLRsX1kA@mail.gmail.com>

Hi all,

The other day on #IRC I mentioned having PermGen issues with the JBossAS
add-on. It's confirmed. During the HoL there are plenty of people who had
the same issue : install the JBoss add-on, start wildfly 8.1, build the
app, deploy it, go to the index.html page (fine), click on an Entity, bang
! PermGen

Alexis Hassler investigated it during the lab (see below). Basically, no
matter what PermGen you set, it's not taken into account.

Again, I really think this add-on should be looked after carefully, it's
very unstable.

Antonio

---------- Forwarded message ----------
From: Alexis Hassler <alexis.hassler at gmail.com>
Date: Tue, Nov 11, 2014 at 11:37 AM
Subject: Re: Forge + Wildfly VM arguments
To: Antonio Goncalves <antonio.goncalves at gmail.com>


Pas de changement avec
as-setup --server wildfly8 --installDir /opt/java/wildfly-8.1.0.Final/
--jvmargs "-Xmx512m -XX:MaxPermSize=256m"


Alexis
http://www.jtips.info, http://blog.alexis-hassler.com,
http://www.lyonjug.org

2014-11-11 11:22 GMT+01:00 Alexis Hassler <alexis.hassler at gmail.com>:

> Avec un wf externe, d?marr? avec as-start.
>
>
>
> ?
> Pour info, en d?marrant un wf 8.1 en ligne de commande "normale" :
> -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m
> -Djava.net.preferIPv4Stack=true
>  -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> -Dorg.jboss.boot.log.file=/opt/java/wildfly-8.1.0.Final/standalone/log/server.log
> -Dlogging.configuration=file:/opt/java/wildfly-8.1.0.Final/standalone/configuration/logging.properties
>
> Alexis
> http://www.jtips.info, http://blog.alexis-hassler.com,
> http://www.lyonjug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141111/d13b4d3a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: forge-wf-jconsole.png
Type: image/png
Size: 414948 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/forge-dev/attachments/20141111/d13b4d3a/attachment-0001.png 

From ggastald at redhat.com  Tue Nov 11 08:13:45 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Tue, 11 Nov 2014 08:13:45 -0500 (EST)
Subject: [forge-dev] Funny exception in generating rest endoint
In-Reply-To: <CA+ZZq9_dAjUnasknSDFuz=7CcPya3K7nTyiqouFU+_p6=1RfBw@mail.gmail.com>
References: <CA+ZZq9_dAjUnasknSDFuz=7CcPya3K7nTyiqouFU+_p6=1RfBw@mail.gmail.com>
Message-ID: <B99C269F-8045-43C8-9C47-657716135D8D@redhat.com>

I've seen that exception before.

He is probably using an old Forge version. Ask him to delete the ~/.forge directory and install the latest version. 


> Em 11/11/2014, ?s 11:08, Antonio Goncalves <antonio.goncalves at gmail.com> escreveu:
> 
> Hi
> 
> During the HoL one guy had this problem (on windows) generating REST endpoints. The generated code is ok, and everything works fine, but here is the stack trace
> 
> 
> ---------- Forwarded message ----------
> From: Ilya Masharov <ilya.masharov at gmail.com>
> Date: 2014-11-11 10:30 GMT+01:00
> Subject: Forge stacktrace
> To: antonio.goncalves at gmail.com
> 
> 
> 
> 11:29:22,655 SEVERE [org.jboss.forge.addon.ui.impl.controller.AbstractCommandController] (AeshProcess: 45) Error while notifying listeners: java.lang.ClassCastException: java.util.ArrayList cannot be cast to org.jboss.forge.addon.resource.FileResource
> 	at org.jboss.forge.addon.projects.Projects.getSelectedProject(Projects.java:37)
> 	at org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener.postCommandExecuted(ProjectBuildStatusListener.java:41)
> 	at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source) [:1.8.0_05]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_05]
> 	at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_05]
> 	at org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:87) [furnace-proxy-2.10.1.Final.jar:2.10.1.Final]
> 	at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:42) [furnace-api-2.10.1.Final.jar:2.10.1.Final]
> 	at org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:103) [furnace-proxy-2.10.1.Final.jar:2.10.1.Final]
> 	at org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.postCommandExecuted(ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.java)
> 	at org.jboss.forge.addon.ui.impl.controller.AbstractCommandController.firePostCommandExecuted(AbstractCommandController.java:144) [ui-impl-2.10.1.Final.jar:2.10.1.Final]
> 	at org.jboss.forge.addon.ui.impl.controller.SingleCommandControllerImpl.execute(SingleCommandControllerImpl.java:89) [ui-impl-2.10.1.Final.jar:2.10.1.Final]
> 	at org.jboss.forge.addon.shell.aesh.CommandAdapter.execute(CommandAdapter.java:74) [shell-impl-2.10.1.Final.jar:2.10.1.Final]
> 	at org.jboss.aesh.console.AeshConsoleImpl$AeshConsoleCallbackImpl.execute(AeshConsoleImpl.java:325) [aesh-0.56.1.jar:0.56.1]
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:40) [aesh-0.56.1.jar:0.56.1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> 
> 
> 
> --
> Antonio Goncalves (antonio.goncalves at gmail.com)
> Software architect
> 
> Web site : www.antoniogoncalves.org
> Blog: agoncal.wordpress.com
> Feed: feeds2.feedburner.com/AntonioGoncalves
> Paris JUG leader : www.parisjug.org
> LinkedIn: www.linkedin.com/in/agoncal
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
> 
> 
> 
> -- 
> Antonio Goncalves 
> Software architect, Java Champion and Pluralsight author
> 
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141111/c080d585/attachment.html 

From vpereira at redhat.com  Tue Nov 11 08:57:37 2014
From: vpereira at redhat.com (Vineet Reynolds Pereira)
Date: Tue, 11 Nov 2014 08:57:37 -0500 (EST)
Subject: [forge-dev] Funny exception in generating rest endoint
In-Reply-To: <CA+ZZq9_dAjUnasknSDFuz=7CcPya3K7nTyiqouFU+_p6=1RfBw@mail.gmail.com>
References: <CA+ZZq9_dAjUnasknSDFuz=7CcPya3K7nTyiqouFU+_p6=1RfBw@mail.gmail.com>
Message-ID: <1428692245.8216409.1415714257790.JavaMail.zimbra@redhat.com>



This looks very much similar to https://issues.jboss.org/browse/FORGE-2017 and it should have been fixed in 2.11.0. Any idea, what version of Forge was used?


----- Original Message -----
> From: "Antonio Goncalves" <antonio.goncalves at gmail.com>
> To: forge-dev at lists.jboss.org
> Sent: Tuesday, November 11, 2014 6:03:25 PM
> Subject: [forge-dev] Funny exception in generating rest endoint
> 
> Hi
> 
> During the HoL one guy had this problem (on windows) generating REST
> endpoints. The generated code is ok, and everything works fine, but here is
> the stack trace
> 
> 
> ---------- Forwarded message ----------
> From: Ilya Masharov < ilya.masharov at gmail.com >
> Date: 2014-11-11 10:30 GMT+01:00
> Subject: Forge stacktrace
> To: antonio.goncalves at gmail.com
> 
> 
> 
> 
> 
> 
> 
> 11:29:22,655 SEVERE
> [org.jboss.forge.addon.ui.impl.controller.AbstractCommandController]
> (AeshProcess: 45) Error while notifying listeners:
> java.lang.ClassCastException: java.util.ArrayList cannot be cast to
> org.jboss.forge.addon.resource.FileResource
> 
> at
> org.jboss.forge.addon.projects.Projects.getSelectedProject(Projects.java:37)
> 
> at
> org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener.postCommandExecuted(ProjectBuildStatusListener.java:41)
> 
> at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source) [:1.8.0_05]
> 
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_05]
> 
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_05]
> 
> at
> org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:87)
> [furnace-proxy-2.10.1.Final.jar:2.10.1.Final]
> 
> at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:42)
> [furnace-api-2.10.1.Final.jar:2.10.1.Final]
> 
> at
> org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:103)
> [furnace-proxy-2.10.1.Final.jar:2.10.1.Final]
> 
> at
> org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.postCommandExecuted(ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.java)
> 
> at
> org.jboss.forge.addon.ui.impl.controller.AbstractCommandController.firePostCommandExecuted(AbstractCommandController.java:144)
> [ui-impl-2.10.1.Final.jar:2.10.1.Final]
> 
> at
> org.jboss.forge.addon.ui.impl.controller.SingleCommandControllerImpl.execute(SingleCommandControllerImpl.java:89)
> [ui-impl-2.10.1.Final.jar:2.10.1.Final]
> 
> at
> org.jboss.forge.addon.shell.aesh.CommandAdapter.execute(CommandAdapter.java:74)
> [shell-impl-2.10.1.Final.jar:2.10.1.Final]
> 
> at
> org.jboss.aesh.console.AeshConsoleImpl$AeshConsoleCallbackImpl.execute(AeshConsoleImpl.java:325)
> [aesh-0.56.1.jar:0.56.1]
> 
> at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:40)
> [aesh-0.56.1.jar:0.56.1]
> 
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [rt.jar:1.8.0_05]
> 
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [rt.jar:1.8.0_05]
> 
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> 
> 
> 
> --
> Antonio Goncalves ( antonio.goncalves at gmail.com )
> Software architect
> 
> Web site : www.antoniogoncalves.org
> Blog: agoncal.wordpress.com
> Feed: feeds2.feedburner.com/AntonioGoncalves
> Paris JUG leader : www.parisjug.org
> LinkedIn: www.linkedin.com/in/agoncal
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
> 
> 
> 
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
> 
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> 
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev

From vpereira at redhat.com  Tue Nov 11 08:59:43 2014
From: vpereira at redhat.com (Vineet Reynolds Pereira)
Date: Tue, 11 Nov 2014 08:59:43 -0500 (EST)
Subject: [forge-dev] Funny exception in generating rest endoint
In-Reply-To: <1428692245.8216409.1415714257790.JavaMail.zimbra@redhat.com>
References: <CA+ZZq9_dAjUnasknSDFuz=7CcPya3K7nTyiqouFU+_p6=1RfBw@mail.gmail.com>
	<1428692245.8216409.1415714257790.JavaMail.zimbra@redhat.com>
Message-ID: <1375142196.8217695.1415714383522.JavaMail.zimbra@redhat.com>


Never mind. I can see the version of Forge used, was 2.10.1 from the stacktrace.

----- Original Message -----
> From: "Vineet Reynolds Pereira" <vpereira at redhat.com>
> To: "forge-dev List" <forge-dev at lists.jboss.org>
> Sent: Tuesday, November 11, 2014 7:27:37 PM
> Subject: Re: [forge-dev] Funny exception in generating rest endoint
> 
> 
> 
> This looks very much similar to https://issues.jboss.org/browse/FORGE-2017
> and it should have been fixed in 2.11.0. Any idea, what version of Forge was
> used?
> 
> 
> ----- Original Message -----
> > From: "Antonio Goncalves" <antonio.goncalves at gmail.com>
> > To: forge-dev at lists.jboss.org
> > Sent: Tuesday, November 11, 2014 6:03:25 PM
> > Subject: [forge-dev] Funny exception in generating rest endoint
> > 
> > Hi
> > 
> > During the HoL one guy had this problem (on windows) generating REST
> > endpoints. The generated code is ok, and everything works fine, but here is
> > the stack trace
> > 
> > 
> > ---------- Forwarded message ----------
> > From: Ilya Masharov < ilya.masharov at gmail.com >
> > Date: 2014-11-11 10:30 GMT+01:00
> > Subject: Forge stacktrace
> > To: antonio.goncalves at gmail.com
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 11:29:22,655 SEVERE
> > [org.jboss.forge.addon.ui.impl.controller.AbstractCommandController]
> > (AeshProcess: 45) Error while notifying listeners:
> > java.lang.ClassCastException: java.util.ArrayList cannot be cast to
> > org.jboss.forge.addon.resource.FileResource
> > 
> > at
> > org.jboss.forge.addon.projects.Projects.getSelectedProject(Projects.java:37)
> > 
> > at
> > org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener.postCommandExecuted(ProjectBuildStatusListener.java:41)
> > 
> > at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source)
> > [:1.8.0_05]
> > 
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > [rt.jar:1.8.0_05]
> > 
> > at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_05]
> > 
> > at
> > org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:87)
> > [furnace-proxy-2.10.1.Final.jar:2.10.1.Final]
> > 
> > at
> > org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:42)
> > [furnace-api-2.10.1.Final.jar:2.10.1.Final]
> > 
> > at
> > org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:103)
> > [furnace-proxy-2.10.1.Final.jar:2.10.1.Final]
> > 
> > at
> > org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.postCommandExecuted(ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.java)
> > 
> > at
> > org.jboss.forge.addon.ui.impl.controller.AbstractCommandController.firePostCommandExecuted(AbstractCommandController.java:144)
> > [ui-impl-2.10.1.Final.jar:2.10.1.Final]
> > 
> > at
> > org.jboss.forge.addon.ui.impl.controller.SingleCommandControllerImpl.execute(SingleCommandControllerImpl.java:89)
> > [ui-impl-2.10.1.Final.jar:2.10.1.Final]
> > 
> > at
> > org.jboss.forge.addon.shell.aesh.CommandAdapter.execute(CommandAdapter.java:74)
> > [shell-impl-2.10.1.Final.jar:2.10.1.Final]
> > 
> > at
> > org.jboss.aesh.console.AeshConsoleImpl$AeshConsoleCallbackImpl.execute(AeshConsoleImpl.java:325)
> > [aesh-0.56.1.jar:0.56.1]
> > 
> > at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:40)
> > [aesh-0.56.1.jar:0.56.1]
> > 
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > [rt.jar:1.8.0_05]
> > 
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > [rt.jar:1.8.0_05]
> > 
> > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> > 
> > 
> > 
> > --
> > Antonio Goncalves ( antonio.goncalves at gmail.com )
> > Software architect
> > 
> > Web site : www.antoniogoncalves.org
> > Blog: agoncal.wordpress.com
> > Feed: feeds2.feedburner.com/AntonioGoncalves
> > Paris JUG leader : www.parisjug.org
> > LinkedIn: www.linkedin.com/in/agoncal
> > 
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > 
> > Note that for all code provided on this list, the provider licenses the
> > code
> > under the Apache License, Version 2 (
> > http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual
> > property rights inherent in such information.
> > 
> > 
> > 
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> > 
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> > 
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
> 

From ggastald at redhat.com  Sat Nov 15 23:11:50 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Sat, 15 Nov 2014 23:11:50 -0500 (EST)
Subject: [forge-dev] Hands-on Lab now available on the website
Message-ID: <1514155746.6475012.1416111110415.JavaMail.zimbra@redhat.com>

Hello everybody,

I made the Hands-On lab tutorial available in the website: http://forge.jboss.org/document/hands-on-lab
There are still some rendering issues (images not being displayed, encoding issues), but we'll fix it in our Redoculous server (the document renderer).
Thanks goes to Antonio Gon?alves, Ivan St. Ivannov and Daniel Cunha and the rest of the Forge community for the contents.

Best Regards,

George Gastaldi


From ivan.st.ivanov at gmail.com  Mon Nov 17 01:58:11 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Mon, 17 Nov 2014 08:58:11 +0200
Subject: [forge-dev] Hands-on Lab now available on the website
In-Reply-To: <1514155746.6475012.1416111110415.JavaMail.zimbra@redhat.com>
References: <1514155746.6475012.1416111110415.JavaMail.zimbra@redhat.com>
Message-ID: <CACYLA9GTk83hC94rwu=O7HOayj6fE27Zv0d=3h4M9VUJSPSVEA@mail.gmail.com>

Hi everybody,

I've added some more sub tasks to the Forge HoL JIRA issue:

https://issues.jboss.org/browse/FORGE-2102

Please feel encouraged to run this lab in your JUG, at your conference,
with your friends and colleagues, etc. We would be more than happy to get
your feedback as sub-task to that issue.

Cheers,
Ivan

P.S. I would like to thank George and Lincoln for the great support and
feedback (and of course, direct fixes ;)) while we were preparing this HoL!

On Sun, Nov 16, 2014 at 6:11 AM, George Gastaldi <ggastald at redhat.com>
wrote:

> Hello everybody,
>
> I made the Hands-On lab tutorial available in the website:
> http://forge.jboss.org/document/hands-on-lab
> There are still some rendering issues (images not being displayed,
> encoding issues), but we'll fix it in our Redoculous server (the document
> renderer).
> Thanks goes to Antonio Gon?alves, Ivan St. Ivannov and Daniel Cunha and
> the rest of the Forge community for the contents.
>
> Best Regards,
>
> George Gastaldi
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141117/2775cb6f/attachment.html 

From ivan.st.ivanov at gmail.com  Mon Nov 24 05:25:14 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Mon, 24 Nov 2014 12:25:14 +0200
Subject: [forge-dev] JPA setup command question
Message-ID: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141124/e53160f5/attachment.html 

From ggastald at redhat.com  Mon Nov 24 06:11:44 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Mon, 24 Nov 2014 06:11:44 -0500 (EST)
Subject: [forge-dev] JPA setup command question
In-Reply-To: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
Message-ID: <23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>

Hi Ivan,

Yes, that's the idea. It's strange that this method is not being called. I'll investigate further. 

Another solution would be to create a new Forge's PersistenceProvider implementation in a separate addon and select that instead when running Jpa:Setup.

Best Regards,

George Gastaldi


> Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
> 
> Hi everybody,
> 
> I have the following usecase. I am developing a web application that uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform (think of it as Tomcat). Which means that I need the Eclipse Link dependencies in the pom.xml in the compile scope. When I generated the project and set up Eclipse Link, I got this in the pom:
> 
>   <dependencies>
>     <dependency>
>       <groupId>org.hibernate.javax.persistence</groupId>
>       <artifactId>hibernate-jpa-2.0-api</artifactId>
>       <scope>provided</scope>
>     </dependency>
>   </dependencies>
> 
> However, I rather need something like:
> 
>         <dependency>
>             <groupId>org.eclipse.persistence</groupId>
>             <artifactId>javax.persistence</artifactId>
>         </dependency>
>         <dependency>
>             <groupId>org.eclipse.persistence</groupId>
>             <artifactId>eclipselink</artifactId>
>         </dependency>
> 
> I see in org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
> 
> 
>    @Override
>    public List<Dependency> listDependencies()
>    {
>       return Arrays.asList((Dependency) DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>                (Dependency) DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>    }
> 
> So we already have functionality on provider level that knows which are the dependencies. However, it seems that this method is not called. What was the idea of having it? How can I make sure that the dependencies are correctly configured? 
> 
> I think that it has something to do with the type of the container: if it is SAP HANA Cloud Platform, then find the dependencies for the JPA provider and add them in the default scope of the pom.xml instead of adding hibernate-jpa-2.0-api. If it is a full fledged application server, then we can go with the API in provided scope. Something like this.
> 
> WDYT?
> 
> Thanks,
> Ivan
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev


From ivan.st.ivanov at gmail.com  Mon Nov 24 07:39:52 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Mon, 24 Nov 2014 14:39:52 +0200
Subject: [forge-dev] JPA setup command question
In-Reply-To: <23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
Message-ID: <CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>

Hi George,

I was thinking of something general in the area of tying up somehow (not
coupling) the JPA containers and providers. The containers know very well
whether they have JPA support at all or, if they have, what is their native
provider (e.g. Hibernate for Wildfly). So IMHO whenever the user specifies
a container with a provider the setup command should do the following:

1) Validate whether this combination is possible at all (e.g. not sure what
will happen if we specify Wildfly with EclipseLink, at the moment it fails)
2) If the current container does not have built-in support for JPA (i.e. it
is based on Tomcat, like SAP HCP) or it supports natively different JPA
provider, then add the listDependencies() content to the pom.xml in the
appropriate scope

Something like this. Not sure though how was this whole thing intended to
work: do we need to fully decouple providers and containers in the JPA
addon?

Cheers,
Ivan

On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com>
wrote:

> Hi Ivan,
>
> Yes, that's the idea. It's strange that this method is not being called.
> I'll investigate further.
>
> Another solution would be to create a new Forge's PersistenceProvider
> implementation in a separate addon and select that instead when running
> Jpa:Setup.
>
> Best Regards,
>
> George Gastaldi
>
>
> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
> escreveu:
> >
> > Hi everybody,
> >
> > I have the following usecase. I am developing a web application that
> uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform
> (think of it as Tomcat). Which means that I need the Eclipse Link
> dependencies in the pom.xml in the compile scope. When I generated the
> project and set up Eclipse Link, I got this in the pom:
> >
> >   <dependencies>
> >     <dependency>
> >       <groupId>org.hibernate.javax.persistence</groupId>
> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
> >       <scope>provided</scope>
> >     </dependency>
> >   </dependencies>
> >
> > However, I rather need something like:
> >
> >         <dependency>
> >             <groupId>org.eclipse.persistence</groupId>
> >             <artifactId>javax.persistence</artifactId>
> >         </dependency>
> >         <dependency>
> >             <groupId>org.eclipse.persistence</groupId>
> >             <artifactId>eclipselink</artifactId>
> >         </dependency>
> >
> > I see in org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
> >
> >
> >    @Override
> >    public List<Dependency> listDependencies()
> >    {
> >       return Arrays.asList((Dependency)
> DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
> >                (Dependency)
> DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
> >    }
> >
> > So we already have functionality on provider level that knows which are
> the dependencies. However, it seems that this method is not called. What
> was the idea of having it? How can I make sure that the dependencies are
> correctly configured?
> >
> > I think that it has something to do with the type of the container: if
> it is SAP HANA Cloud Platform, then find the dependencies for the JPA
> provider and add them in the default scope of the pom.xml instead of adding
> hibernate-jpa-2.0-api. If it is a full fledged application server, then we
> can go with the API in provided scope. Something like this.
> >
> > WDYT?
> >
> > Thanks,
> > Ivan
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141124/abcc0c9a/attachment.html 

From ggastald at redhat.com  Mon Nov 24 08:26:55 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Mon, 24 Nov 2014 11:26:55 -0200
Subject: [forge-dev] JPA setup command question
In-Reply-To: <CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
Message-ID: <5473321F.5090302@redhat.com>

Right, I think this makes sense. We might need to add more tests under 
these conditions. This area sure needs a bit of improvement.

It looks like SAPHanaCloudPlatformContainer shouldn't be extending 
JavaEEDefaultContainer, afaik that is only meant to be extended by 
implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic, 
GlassFish).

On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
> Hi George,
>
> I was thinking of something general in the area of tying up 
> somehow (not coupling) the JPA containers and providers. The 
> containers know very well whether they have JPA support at all or, if 
> they have, what is their native provider (e.g. Hibernate for Wildfly). 
> So IMHO whenever the user specifies a container with a provider the 
> setup command should do the following:
>
> 1) Validate whether this combination is possible at all (e.g. not sure 
> what will happen if we specify Wildfly with EclipseLink, at the moment 
> it fails)
> 2) If the current container does not have built-in support for JPA 
> (i.e. it is based on Tomcat, like SAP HCP) or it supports natively 
> different JPA provider, then add the listDependencies() content to the 
> pom.xml in the appropriate scope
>
> Something like this. Not sure though how was this whole thing intended 
> to work: do we need to fully decouple providers and containers in the 
> JPA addon?
>
> Cheers,
> Ivan
>
> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com 
> <mailto:ggastald at redhat.com>> wrote:
>
>     Hi Ivan,
>
>     Yes, that's the idea. It's strange that this method is not being
>     called. I'll investigate further.
>
>     Another solution would be to create a new Forge's
>     PersistenceProvider implementation in a separate addon and select
>     that instead when running Jpa:Setup.
>
>     Best Regards,
>
>     George Gastaldi
>
>
>     > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov
>     <ivan.st.ivanov at gmail.com <mailto:ivan.st.ivanov at gmail.com>> escreveu:
>     >
>     > Hi everybody,
>     >
>     > I have the following usecase. I am developing a web application
>     that uses JPA with Eclipse Link and will be deployed on SAP HANA
>     Cloud Platform (think of it as Tomcat). Which means that I need
>     the Eclipse Link dependencies in the pom.xml in the compile scope.
>     When I generated the project and set up Eclipse Link, I got this
>     in the pom:
>     >
>     >   <dependencies>
>     >     <dependency>
>     >  <groupId>org.hibernate.javax.persistence</groupId>
>     >  <artifactId>hibernate-jpa-2.0-api</artifactId>
>     >       <scope>provided</scope>
>     >     </dependency>
>     >   </dependencies>
>     >
>     > However, I rather need something like:
>     >
>     >         <dependency>
>     >  <groupId>org.eclipse.persistence</groupId>
>     >  <artifactId>javax.persistence</artifactId>
>     >         </dependency>
>     >         <dependency>
>     >  <groupId>org.eclipse.persistence</groupId>
>     >  <artifactId>eclipselink</artifactId>
>     >         </dependency>
>     >
>     > I see in
>     org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>     >
>     >
>     >    @Override
>     >    public List<Dependency> listDependencies()
>     >    {
>     >       return Arrays.asList((Dependency)
>     DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>     >                (Dependency)
>     DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>     >    }
>     >
>     > So we already have functionality on provider level that knows
>     which are the dependencies. However, it seems that this method is
>     not called. What was the idea of having it? How can I make sure
>     that the dependencies are correctly configured?
>     >
>     > I think that it has something to do with the type of the
>     container: if it is SAP HANA Cloud Platform, then find the
>     dependencies for the JPA provider and add them in the default
>     scope of the pom.xml instead of adding hibernate-jpa-2.0-api. If
>     it is a full fledged application server, then we can go with the
>     API in provided scope. Something like this.
>     >
>     > WDYT?
>     >
>     > Thanks,
>     > Ivan
>     > _______________________________________________
>     > forge-dev mailing list
>     > forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/forge-dev
>
>     _______________________________________________
>     forge-dev mailing list
>     forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141124/adf9ca9c/attachment-0001.html 

From ivan.st.ivanov at gmail.com  Wed Nov 26 03:56:43 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Wed, 26 Nov 2014 10:56:43 +0200
Subject: [forge-dev] JPA setup command question
In-Reply-To: <5473321F.5090302@redhat.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
	<5473321F.5090302@redhat.com>
Message-ID: <CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>

Hi George,

I can work on providing those tests and crafting a solution for the case
when the JPA provider is not packed with the target container. Will jump in
the IRC channel this week and discuss in more details with you.

I see that the JavaEEDefaultContainer implements methods that imply JTA
data source. No matter that SAP HCP is built on top of Tomcat, we have our
own persistence service, which provides JTA data source. So, generally you
are right that I should not extend that abstract class, but in this
concrete case with HANA Cloud Platform it is the right thing to do.

Cheers,
Ivan

On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald at redhat.com>
wrote:

>  Right, I think this makes sense. We might need to add more tests under
> these conditions. This area sure needs a bit of improvement.
>
>  It looks like SAPHanaCloudPlatformContainer shouldn't be extending
> JavaEEDefaultContainer, afaik that is only meant to be extended by
> implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic,
> GlassFish).
>
>  On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
>
> Hi George,
>
>  I was thinking of something general in the area of tying up somehow (not
> coupling) the JPA containers and providers. The containers know very well
> whether they have JPA support at all or, if they have, what is their native
> provider (e.g. Hibernate for Wildfly). So IMHO whenever the user specifies
> a container with a provider the setup command should do the following:
>
>  1) Validate whether this combination is possible at all (e.g. not sure
> what will happen if we specify Wildfly with EclipseLink, at the moment it
> fails)
> 2) If the current container does not have built-in support for JPA (i.e.
> it is based on Tomcat, like SAP HCP) or it supports natively different JPA
> provider, then add the listDependencies() content to the pom.xml in the
> appropriate scope
>
>  Something like this. Not sure though how was this whole thing intended
> to work: do we need to fully decouple providers and containers in the JPA
> addon?
>
>  Cheers,
> Ivan
>
> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com>
> wrote:
>
>> Hi Ivan,
>>
>> Yes, that's the idea. It's strange that this method is not being called.
>> I'll investigate further.
>>
>> Another solution would be to create a new Forge's PersistenceProvider
>> implementation in a separate addon and select that instead when running
>> Jpa:Setup.
>>
>> Best Regards,
>>
>> George Gastaldi
>>
>>
>> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>> escreveu:
>>  >
>> > Hi everybody,
>> >
>> > I have the following usecase. I am developing a web application that
>> uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform
>> (think of it as Tomcat). Which means that I need the Eclipse Link
>> dependencies in the pom.xml in the compile scope. When I generated the
>> project and set up Eclipse Link, I got this in the pom:
>> >
>> >   <dependencies>
>> >     <dependency>
>> >       <groupId>org.hibernate.javax.persistence</groupId>
>> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
>> >       <scope>provided</scope>
>> >     </dependency>
>> >   </dependencies>
>> >
>> > However, I rather need something like:
>> >
>> >         <dependency>
>> >             <groupId>org.eclipse.persistence</groupId>
>> >             <artifactId>javax.persistence</artifactId>
>> >         </dependency>
>> >         <dependency>
>> >             <groupId>org.eclipse.persistence</groupId>
>> >             <artifactId>eclipselink</artifactId>
>> >         </dependency>
>> >
>> > I see in org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>> >
>> >
>> >    @Override
>> >    public List<Dependency> listDependencies()
>> >    {
>> >       return Arrays.asList((Dependency)
>> DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>> >                (Dependency)
>> DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>> >    }
>> >
>> > So we already have functionality on provider level that knows which are
>> the dependencies. However, it seems that this method is not called. What
>> was the idea of having it? How can I make sure that the dependencies are
>> correctly configured?
>> >
>> > I think that it has something to do with the type of the container: if
>> it is SAP HANA Cloud Platform, then find the dependencies for the JPA
>> provider and add them in the default scope of the pom.xml instead of adding
>> hibernate-jpa-2.0-api. If it is a full fledged application server, then we
>> can go with the API in provided scope. Something like this.
>> >
>> > WDYT?
>> >
>> > Thanks,
>> > Ivan
>>  > _______________________________________________
>> > forge-dev mailing list
>> > forge-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
>
> _______________________________________________
> forge-dev mailing listforge-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141126/9eb7701e/attachment.html 

From ivan.st.ivanov at gmail.com  Wed Nov 26 04:08:45 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Wed, 26 Nov 2014 11:08:45 +0200
Subject: [forge-dev] Building Forge with Java 8
Message-ID: <CACYLA9FMG-WJUu31J7cKzTgg3PZKf+=GZK_xjgxMDqWOqht1=Q@mail.gmail.com>

Hi everybody,

As some of you noticed, last night I was able to build and run Forge with
the latest early access build of Open JDK 9 (from the Jigsaw forest!). I
had to do just one manual workaround. I had to manually add the following
dependency to the javaee/impl/pom.xml and shell/impl/pom.xml:

      <dependency>
         <groupId>org.jboss.forge.furnace.container</groupId>
         <artifactId>simple-api</artifactId>
         <scope>provided</scope>
      </dependency>

It was a problem that was already found and documented in this JIRA:

https://issues.jboss.org/browse/FORGE-2019

The JIRA says that this problem occurs with Java 8, build 20. So my
question is whether this is fixed in later builds of Java 8. If yes, I will
report this to the Open JDK folks to up-port the fix to Java 9 as well. If
not, I guess we should fix the poms of the respective projects?

Thanks,
Ivan

P.S. Sorry for the 'lazy web' style of message. I know I could have run the
build with newer Java 8 by myself :)
P.P.S. Thanks to Mani Sarkar from LJC that went the hard way last week and
found this workaround for me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141126/a35cd252/attachment.html 

From vpereira at redhat.com  Wed Nov 26 04:55:04 2014
From: vpereira at redhat.com (Vineet Reynolds Pereira)
Date: Wed, 26 Nov 2014 04:55:04 -0500 (EST)
Subject: [forge-dev] Building Forge with Java 8
In-Reply-To: <CACYLA9FMG-WJUu31J7cKzTgg3PZKf+=GZK_xjgxMDqWOqht1=Q@mail.gmail.com>
References: <CACYLA9FMG-WJUu31J7cKzTgg3PZKf+=GZK_xjgxMDqWOqht1=Q@mail.gmail.com>
Message-ID: <1676304628.10357168.1416995704909.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Ivan St. Ivanov" <ivan.st.ivanov at gmail.com>
> To: "forge-dev List" <forge-dev at lists.jboss.org>
> Cc: "Mani Sarkar" <sadhak001 at gmail.com>
> Sent: Wednesday, November 26, 2014 2:38:45 PM
> Subject: [forge-dev] Building Forge with Java 8
> 
> Hi everybody,
> 
> As some of you noticed, last night I was able to build and run Forge with the
> latest early access build of Open JDK 9 (from the Jigsaw forest!). I had to
> do just one manual workaround. I had to manually add the following
> dependency to the javaee/impl/pom.xml and shell/impl/pom.xml:
> 
> <dependency>
> <groupId>org.jboss.forge.furnace.container</groupId>
> <artifactId>simple-api</artifactId>
> <scope>provided</scope>
> </dependency>
> 
> It was a problem that was already found and documented in this JIRA:
> 
> https://issues.jboss.org/browse/FORGE-2019
> 
> The JIRA says that this problem occurs with Java 8, build 20. So my question
> is whether this is fixed in later builds of Java 8. If yes, I will report
> this to the Open JDK folks to up-port the fix to Java 9 as well. If not, I
> guess we should fix the poms of the respective projects?

I believe this is a known bug in OpenJDK (link anyone?) and it has broken other project builds as well.
It is unfixed as of 8u25 (tested it yesterday), so we're using older versions of JDK to build Forge.

And the POMs should not be fixed; that would be the wrong way to go about it (see George's comment in the JIRA).

> 
> Thanks,
> Ivan
> 
> P.S. Sorry for the 'lazy web' style of message. I know I could have run the
> build with newer Java 8 by myself :)
> P.P.S. Thanks to Mani Sarkar from LJC that went the hard way last week and
> found this workaround for me
> 
> 
> 
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev

From ggastald at redhat.com  Wed Nov 26 07:06:30 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Wed, 26 Nov 2014 07:06:30 -0500 (EST)
Subject: [forge-dev] Building Forge with Java 8
In-Reply-To: <CACYLA9FMG-WJUu31J7cKzTgg3PZKf+=GZK_xjgxMDqWOqht1=Q@mail.gmail.com>
References: <CACYLA9FMG-WJUu31J7cKzTgg3PZKf+=GZK_xjgxMDqWOqht1=Q@mail.gmail.com>
Message-ID: <599FD830-BC9E-4B13-BA75-C3D6ABAC20EF@redhat.com>

Hi Ivan, 
This is still not fixed in later versions of JDK8.
JDK 1.8.0_11 is the last JDK version where forge builds/runs.

I guess one option is that we'll have to make our services derived from the simple service NOT implement the Service interface. This is not required atm, but the javadoc says that it is possible.

However, I think we might run in runtime issues when the addon boots up due to lacking dependencies. That's all I remember from working in this issue


> Em 26/11/2014, ?s 07:09, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
> 
> Hi everybody,
> 
> As some of you noticed, last night I was able to build and run Forge with the latest early access build of Open JDK 9 (from the Jigsaw forest!). I had to do just one manual workaround. I had to manually add the following dependency to the javaee/impl/pom.xml and shell/impl/pom.xml:
> 
>       <dependency>
>          <groupId>org.jboss.forge.furnace.container</groupId>
>          <artifactId>simple-api</artifactId>
>          <scope>provided</scope>
>       </dependency>
> 
> It was a problem that was already found and documented in this JIRA:
> 
> https://issues.jboss.org/browse/FORGE-2019
> 
> The JIRA says that this problem occurs with Java 8, build 20. So my question is whether this is fixed in later builds of Java 8. If yes, I will report this to the Open JDK folks to up-port the fix to Java 9 as well. If not, I guess we should fix the poms of the respective projects?
> 
> Thanks,
> Ivan
> 
> P.S. Sorry for the 'lazy web' style of message. I know I could have run the build with newer Java 8 by myself :)
> P.P.S. Thanks to Mani Sarkar from LJC that went the hard way last week and found this workaround for me 
> 
> 
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141126/e4a3b643/attachment-0001.html 

From ggastald at redhat.com  Wed Nov 26 13:54:01 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Wed, 26 Nov 2014 16:54:01 -0200
Subject: [forge-dev] Reflections Addon
Message-ID: <547621C9.8010704@redhat.com>

Hello everyone!

I just made available an addon to allow Java runtime metadata analysis 
from a Project.
I am using the excellent library Reflections 
(https://github.com/ronmamo/reflections) and made available through facets.
Feel free to add more funcionality if you want (maybe a command to query 
for structure information inside Forge?)

Github Repo: https://github.com/gastaldi/reflections-addon
Instructions: http://forge.jboss.org/addon/me.gastaldi.forge:reflections

Best Regards,
-- 

*George Gastaldi | Senior Software Engineer*
JBoss Forge Team
T: +55 11 3524-6169
M: +55 47 9711-1000

Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at www.redhat.com <http://www.redhat.com/>

LinkedIn <http://www.linkedin.com/company/3258288> Youtube 
<https://www.youtube.com/redhatlatam>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141126/ab02bc7d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: {a8aabf3a-4467-4e37-9bc5-48b1d7b494a2}_LATAM_RedHat.jpg
Type: image/jpeg
Size: 4815 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/forge-dev/attachments/20141126/ab02bc7d/attachment.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin.png
Type: image/png
Size: 597 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/forge-dev/attachments/20141126/ab02bc7d/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: youtube.png
Type: image/png
Size: 616 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/forge-dev/attachments/20141126/ab02bc7d/attachment-0001.png 

From ivan.st.ivanov at gmail.com  Wed Nov 26 14:09:30 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Wed, 26 Nov 2014 21:09:30 +0200
Subject: [forge-dev] Building Forge with Java 8
In-Reply-To: <599FD830-BC9E-4B13-BA75-C3D6ABAC20EF@redhat.com>
References: <CACYLA9FMG-WJUu31J7cKzTgg3PZKf+=GZK_xjgxMDqWOqht1=Q@mail.gmail.com>
	<599FD830-BC9E-4B13-BA75-C3D6ABAC20EF@redhat.com>
Message-ID: <CACYLA9Fa7ZBiecLBK8GeZm5pvuFAMbG5GQVri4NUvF2wCL3shg@mail.gmail.com>

Hi George,

While reading the JIRA again and again it seems that this is a feature, not
a bug in javac. So it will be here to stay. Which means that it is us that
have to think about a solution. Probably that is why the issue is still
open :)

Cheers,
Ivan

On Wed, Nov 26, 2014 at 2:06 PM, George Gastaldi <ggastald at redhat.com>
wrote:

> Hi Ivan,
> This is still not fixed in later versions of JDK8.
> JDK 1.8.0_11 is the last JDK version where forge builds/runs.
>
> I guess one option is that we'll have to make our services derived from
> the simple service NOT implement the Service interface. This is not
> required atm, but the javadoc says that it is possible.
>
> However, I think we might run in runtime issues when the addon boots up
> due to lacking dependencies. That's all I remember from working in this
> issue
>
>
> Em 26/11/2014, ?s 07:09, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
> escreveu:
>
> Hi everybody,
>
> As some of you noticed, last night I was able to build and run Forge with
> the latest early access build of Open JDK 9 (from the Jigsaw forest!). I
> had to do just one manual workaround. I had to manually add the following
> dependency to the javaee/impl/pom.xml and shell/impl/pom.xml:
>
>       <dependency>
>          <groupId>org.jboss.forge.furnace.container</groupId>
>          <artifactId>simple-api</artifactId>
>          <scope>provided</scope>
>       </dependency>
>
> It was a problem that was already found and documented in this JIRA:
>
> https://issues.jboss.org/browse/FORGE-2019
>
> The JIRA says that this problem occurs with Java 8, build 20. So my
> question is whether this is fixed in later builds of Java 8. If yes, I will
> report this to the Open JDK folks to up-port the fix to Java 9 as well. If
> not, I guess we should fix the poms of the respective projects?
>
> Thanks,
> Ivan
>
> P.S. Sorry for the 'lazy web' style of message. I know I could have run
> the build with newer Java 8 by myself :)
> P.P.S. Thanks to Mani Sarkar from LJC that went the hard way last week and
> found this workaround for me
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141126/bbd758da/attachment.html 

From ggastald at redhat.com  Wed Nov 26 14:12:13 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Wed, 26 Nov 2014 17:12:13 -0200
Subject: [forge-dev] Building Forge with Java 8
In-Reply-To: <CACYLA9Fa7ZBiecLBK8GeZm5pvuFAMbG5GQVri4NUvF2wCL3shg@mail.gmail.com>
References: <CACYLA9FMG-WJUu31J7cKzTgg3PZKf+=GZK_xjgxMDqWOqht1=Q@mail.gmail.com>	<599FD830-BC9E-4B13-BA75-C3D6ABAC20EF@redhat.com>
	<CACYLA9Fa7ZBiecLBK8GeZm5pvuFAMbG5GQVri4NUvF2wCL3shg@mail.gmail.com>
Message-ID: <5476260D.8080504@redhat.com>

Hi Ivan,

Good call, I changed it to "New Feature".
Thanks for pointing that out.

Best Regards,

George Gastaldi

On 11/26/2014 05:09 PM, Ivan St. Ivanov wrote:
> Hi George,
>
> While reading the JIRA again and again it seems that this is a 
> feature, not a bug in javac. So it will be here to stay. Which means 
> that it is us that have to think about a solution. Probably that is 
> why the issue is still open :)
>
> Cheers,
> Ivan
>
> On Wed, Nov 26, 2014 at 2:06 PM, George Gastaldi <ggastald at redhat.com 
> <mailto:ggastald at redhat.com>> wrote:
>
>     Hi Ivan,
>     This is still not fixed in later versions of JDK8.
>     JDK 1.8.0_11 is the last JDK version where forge builds/runs.
>
>     I guess one option is that we'll have to make our services derived
>     from the simple service NOT implement the Service interface. This
>     is not required atm, but the javadoc says that it is possible.
>
>     However, I think we might run in runtime issues when the addon
>     boots up due to lacking dependencies. That's all I remember from
>     working in this issue
>
>
>     Em 26/11/2014, ?s 07:09, Ivan St. Ivanov <ivan.st.ivanov at gmail.com
>     <mailto:ivan.st.ivanov at gmail.com>> escreveu:
>
>>     Hi everybody,
>>
>>     As some of you noticed, last night I was able to build and run
>>     Forge with the latest early access build of Open JDK 9 (from the
>>     Jigsaw forest!). I had to do just one manual workaround. I had to
>>     manually add the following dependency to the javaee/impl/pom.xml
>>     and shell/impl/pom.xml:
>>
>>     <dependency>
>>     <groupId>org.jboss.forge.furnace.container</groupId>
>>     <artifactId>simple-api</artifactId>
>>     <scope>provided</scope>
>>     </dependency>
>>     It was a problem that was already found and documented in this JIRA:
>>
>>     https://issues.jboss.org/browse/FORGE-2019
>>
>>     The JIRA says that this problem occurs with Java 8, build 20. So
>>     my question is whether this is fixed in later builds of Java 8.
>>     If yes, I will report this to the Open JDK folks to up-port the
>>     fix to Java 9 as well. If not, I guess we should fix the poms of
>>     the respective projects?
>>
>>     Thanks,
>>     Ivan
>>
>>     P.S. Sorry for the 'lazy web' style of message. I know I could
>>     have run the build with newer Java 8 by myself :)
>>     P.P.S. Thanks to Mani Sarkar from LJC that went the hard way last
>>     week and found this workaround for me
>>
>>
>>     _______________________________________________
>>     forge-dev mailing list
>>     forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/forge-dev
>
>     _______________________________________________
>     forge-dev mailing list
>     forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141126/ad9695b1/attachment-0001.html 

From ivan.st.ivanov at gmail.com  Thu Nov 27 16:28:42 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Thu, 27 Nov 2014 23:28:42 +0200
Subject: [forge-dev] JPA setup command question
In-Reply-To: <CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
	<5473321F.5090302@redhat.com>
	<CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>
Message-ID: <CACYLA9G=VnQv8CzcGdYaLLe4d-NtBCMNONWBjbbW23M-MZ9pFQ@mail.gmail.com>

So I was preparing the test. I wanted to create a test case that prints the
content of the pom.xml after it invokes the setup command. Here is how I
prepare everything:

@Inject
private UITestHarness testHarness;

@Inject
private ProjectFactory projectFactory;

@Inject
private EclipseLinkProvider provider;

@Inject
private WildflyContainer wildflyContainer;

@Test
public void testPomXmlContent() throws Exception
{
   Project project = projectFactory.createTempProject();
   WizardCommandController tester =
testHarness.createWizardController(JPASetupWizard.class,
            project.getRoot());

   tester.initialize();

   // Setting UI values
   tester.setValueFor("jpaVersion", "2.1");
   tester.setValueFor("provider", provider);
   tester.setValueFor("container", wildflyContainer);

   tester.next().initialize();

   Assert.assertTrue(tester.isValid());
   tester.execute();
}

And now I want to somehow get the dependency facet or some other facet and
print the content of pom.xml (or the dependencies). How can I do that?

Thanks,
Ivan

On Wed, Nov 26, 2014 at 10:56 AM, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
wrote:

> Hi George,
>
> I can work on providing those tests and crafting a solution for the case
> when the JPA provider is not packed with the target container. Will jump in
> the IRC channel this week and discuss in more details with you.
>
> I see that the JavaEEDefaultContainer implements methods that imply JTA
> data source. No matter that SAP HCP is built on top of Tomcat, we have our
> own persistence service, which provides JTA data source. So, generally you
> are right that I should not extend that abstract class, but in this
> concrete case with HANA Cloud Platform it is the right thing to do.
>
> Cheers,
> Ivan
>
> On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald at redhat.com>
> wrote:
>
>>  Right, I think this makes sense. We might need to add more tests under
>> these conditions. This area sure needs a bit of improvement.
>>
>>  It looks like SAPHanaCloudPlatformContainer shouldn't be extending
>> JavaEEDefaultContainer, afaik that is only meant to be extended by
>> implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic,
>> GlassFish).
>>
>>  On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
>>
>> Hi George,
>>
>>  I was thinking of something general in the area of tying up
>> somehow (not coupling) the JPA containers and providers. The containers
>> know very well whether they have JPA support at all or, if they have, what
>> is their native provider (e.g. Hibernate for Wildfly). So IMHO whenever the
>> user specifies a container with a provider the setup command should do the
>> following:
>>
>>  1) Validate whether this combination is possible at all (e.g. not sure
>> what will happen if we specify Wildfly with EclipseLink, at the moment it
>> fails)
>> 2) If the current container does not have built-in support for JPA (i.e.
>> it is based on Tomcat, like SAP HCP) or it supports natively different JPA
>> provider, then add the listDependencies() content to the pom.xml in the
>> appropriate scope
>>
>>  Something like this. Not sure though how was this whole thing intended
>> to work: do we need to fully decouple providers and containers in the JPA
>> addon?
>>
>>  Cheers,
>> Ivan
>>
>> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com>
>> wrote:
>>
>>> Hi Ivan,
>>>
>>> Yes, that's the idea. It's strange that this method is not being called.
>>> I'll investigate further.
>>>
>>> Another solution would be to create a new Forge's PersistenceProvider
>>> implementation in a separate addon and select that instead when running
>>> Jpa:Setup.
>>>
>>> Best Regards,
>>>
>>> George Gastaldi
>>>
>>>
>>> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>>> escreveu:
>>>  >
>>> > Hi everybody,
>>> >
>>> > I have the following usecase. I am developing a web application that
>>> uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform
>>> (think of it as Tomcat). Which means that I need the Eclipse Link
>>> dependencies in the pom.xml in the compile scope. When I generated the
>>> project and set up Eclipse Link, I got this in the pom:
>>> >
>>> >   <dependencies>
>>> >     <dependency>
>>> >       <groupId>org.hibernate.javax.persistence</groupId>
>>> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
>>> >       <scope>provided</scope>
>>> >     </dependency>
>>> >   </dependencies>
>>> >
>>> > However, I rather need something like:
>>> >
>>> >         <dependency>
>>> >             <groupId>org.eclipse.persistence</groupId>
>>> >             <artifactId>javax.persistence</artifactId>
>>> >         </dependency>
>>> >         <dependency>
>>> >             <groupId>org.eclipse.persistence</groupId>
>>> >             <artifactId>eclipselink</artifactId>
>>> >         </dependency>
>>> >
>>> > I see in
>>> org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>>> >
>>> >
>>> >    @Override
>>> >    public List<Dependency> listDependencies()
>>> >    {
>>> >       return Arrays.asList((Dependency)
>>> DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>>> >                (Dependency)
>>> DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>>> >    }
>>> >
>>> > So we already have functionality on provider level that knows which
>>> are the dependencies. However, it seems that this method is not called.
>>> What was the idea of having it? How can I make sure that the dependencies
>>> are correctly configured?
>>> >
>>> > I think that it has something to do with the type of the container: if
>>> it is SAP HANA Cloud Platform, then find the dependencies for the JPA
>>> provider and add them in the default scope of the pom.xml instead of adding
>>> hibernate-jpa-2.0-api. If it is a full fledged application server, then we
>>> can go with the API in provided scope. Something like this.
>>> >
>>> > WDYT?
>>> >
>>> > Thanks,
>>> > Ivan
>>>  > _______________________________________________
>>> > forge-dev mailing list
>>> > forge-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing listforge-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141127/d5185c1b/attachment.html 

From ggastald at redhat.com  Thu Nov 27 16:35:07 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Thu, 27 Nov 2014 16:35:07 -0500 (EST)
Subject: [forge-dev] JPA setup command question
In-Reply-To: <CACYLA9G=VnQv8CzcGdYaLLe4d-NtBCMNONWBjbbW23M-MZ9pFQ@mail.gmail.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
	<5473321F.5090302@redhat.com>
	<CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>
	<CACYLA9G=VnQv8CzcGdYaLLe4d-NtBCMNONWBjbbW23M-MZ9pFQ@mail.gmail.com>
Message-ID: <0B093E63-9DD8-46E2-B060-CC713BEA0DC3@redhat.com>

Try doing project.getFacet(MavenFacet.class).getModel() and you should have the pom.xml model available



> Em 27/11/2014, ?s 19:28, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
> 
> So I was preparing the test. I wanted to create a test case that prints the content of the pom.xml after it invokes the setup command. Here is how I prepare everything:
> 
> @Inject
> private UITestHarness testHarness;
> 
> @Inject
> private ProjectFactory projectFactory;
> 
> @Inject
> private EclipseLinkProvider provider;
> 
> @Inject
> private WildflyContainer wildflyContainer;
> @Test
> public void testPomXmlContent() throws Exception
> {
>    Project project = projectFactory.createTempProject();
>    WizardCommandController tester = testHarness.createWizardController(JPASetupWizard.class,
>             project.getRoot());
> 
>    tester.initialize();
> 
>    // Setting UI values
>    tester.setValueFor("jpaVersion", "2.1");
>    tester.setValueFor("provider", provider);
>    tester.setValueFor("container", wildflyContainer);
> 
>    tester.next().initialize();
> 
>    Assert.assertTrue(tester.isValid());
>    tester.execute();
> }
> And now I want to somehow get the dependency facet or some other facet and print the content of pom.xml (or the dependencies). How can I do that?
> 
> Thanks,
> Ivan
> 
>> On Wed, Nov 26, 2014 at 10:56 AM, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> wrote:
>> Hi George,
>> 
>> I can work on providing those tests and crafting a solution for the case when the JPA provider is not packed with the target container. Will jump in the IRC channel this week and discuss in more details with you.
>> 
>> I see that the JavaEEDefaultContainer implements methods that imply JTA data source. No matter that SAP HCP is built on top of Tomcat, we have our own persistence service, which provides JTA data source. So, generally you are right that I should not extend that abstract class, but in this concrete case with HANA Cloud Platform it is the right thing to do.
>> 
>> Cheers,
>> Ivan
>> 
>>> On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>> Right, I think this makes sense. We might need to add more tests under these conditions. This area sure needs a bit of improvement.
>>> 
>>> It looks like SAPHanaCloudPlatformContainer shouldn't be extending JavaEEDefaultContainer, afaik that is only meant to be extended by implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic, GlassFish).
>>> 
>>>> On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
>>>> Hi George,
>>>> 
>>>> I was thinking of something general in the area of tying up somehow (not coupling) the JPA containers and providers. The containers know very well whether they have JPA support at all or, if they have, what is their native provider (e.g. Hibernate for Wildfly). So IMHO whenever the user specifies a container with a provider the setup command should do the following:
>>>> 
>>>> 1) Validate whether this combination is possible at all (e.g. not sure what will happen if we specify Wildfly with EclipseLink, at the moment it fails)
>>>> 2) If the current container does not have built-in support for JPA (i.e. it is based on Tomcat, like SAP HCP) or it supports natively different JPA provider, then add the listDependencies() content to the pom.xml in the appropriate scope
>>>> 
>>>> Something like this. Not sure though how was this whole thing intended to work: do we need to fully decouple providers and containers in the JPA addon?
>>>> 
>>>> Cheers,
>>>> Ivan
>>>> 
>>>>> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>> Hi Ivan,
>>>>> 
>>>>> Yes, that's the idea. It's strange that this method is not being called. I'll investigate further.
>>>>> 
>>>>> Another solution would be to create a new Forge's PersistenceProvider implementation in a separate addon and select that instead when running Jpa:Setup.
>>>>> 
>>>>> Best Regards,
>>>>> 
>>>>> George Gastaldi
>>>>> 
>>>>> 
>>>>> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>>>> >
>>>>> > Hi everybody,
>>>>> >
>>>>> > I have the following usecase. I am developing a web application that uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform (think of it as Tomcat). Which means that I need the Eclipse Link dependencies in the pom.xml in the compile scope. When I generated the project and set up Eclipse Link, I got this in the pom:
>>>>> >
>>>>> >   <dependencies>
>>>>> >     <dependency>
>>>>> >       <groupId>org.hibernate.javax.persistence</groupId>
>>>>> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
>>>>> >       <scope>provided</scope>
>>>>> >     </dependency>
>>>>> >   </dependencies>
>>>>> >
>>>>> > However, I rather need something like:
>>>>> >
>>>>> >         <dependency>
>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>> >             <artifactId>javax.persistence</artifactId>
>>>>> >         </dependency>
>>>>> >         <dependency>
>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>> >             <artifactId>eclipselink</artifactId>
>>>>> >         </dependency>
>>>>> >
>>>>> > I see in org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>>>>> >
>>>>> >
>>>>> >    @Override
>>>>> >    public List<Dependency> listDependencies()
>>>>> >    {
>>>>> >       return Arrays.asList((Dependency) DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>>>>> >                (Dependency) DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>>>>> >    }
>>>>> >
>>>>> > So we already have functionality on provider level that knows which are the dependencies. However, it seems that this method is not called. What was the idea of having it? How can I make sure that the dependencies are correctly configured?
>>>>> >
>>>>> > I think that it has something to do with the type of the container: if it is SAP HANA Cloud Platform, then find the dependencies for the JPA provider and add them in the default scope of the pom.xml instead of adding hibernate-jpa-2.0-api. If it is a full fledged application server, then we can go with the API in provided scope. Something like this.
>>>>> >
>>>>> > WDYT?
>>>>> >
>>>>> > Thanks,
>>>>> > Ivan
>>>>> > _______________________________________________
>>>>> > forge-dev mailing list
>>>>> > forge-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>> 
>>>>> _______________________________________________
>>>>> forge-dev mailing list
>>>>> forge-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> 
>>> 
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
> 
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141127/45330b68/attachment-0001.html 

From ivan.st.ivanov at gmail.com  Thu Nov 27 16:57:52 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Thu, 27 Nov 2014 23:57:52 +0200
Subject: [forge-dev] JPA setup command question
In-Reply-To: <0B093E63-9DD8-46E2-B060-CC713BEA0DC3@redhat.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
	<5473321F.5090302@redhat.com>
	<CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>
	<CACYLA9G=VnQv8CzcGdYaLLe4d-NtBCMNONWBjbbW23M-MZ9pFQ@mail.gmail.com>
	<0B093E63-9DD8-46E2-B060-CC713BEA0DC3@redhat.com>
Message-ID: <CACYLA9FwKhx4oRjkb6ciVNXjfWwUG18cOVYx48VWRL6bFCfKtg@mail.gmail.com>

Thanks George!

So I have attached the test. You can put it in the javaee addon, under the
test folder. It's located in the org.jboss.forge.addon.javaee.jpa.ui.setup
package. After you run it, look for the 'dependencies = ' string in the
output. I've set it up to use EclipseLink on Wildfly container. I suppose
it is not going to work with the JPA API dependency only, is it?

Cheers,
Ivan

On Thu, Nov 27, 2014 at 11:35 PM, George Gastaldi <ggastald at redhat.com>
wrote:

> Try doing project.getFacet(MavenFacet.class).getModel() and you should
> have the pom.xml model available
>
>
>
> Em 27/11/2014, ?s 19:28, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
> escreveu:
>
> So I was preparing the test. I wanted to create a test case that prints
> the content of the pom.xml after it invokes the setup command. Here is how
> I prepare everything:
>
> @Inject
> private UITestHarness testHarness;
>
> @Inject
> private ProjectFactory projectFactory;
>
> @Inject
> private EclipseLinkProvider provider;
>
> @Inject
> private WildflyContainer wildflyContainer;
>
> @Test
> public void testPomXmlContent() throws Exception
> {
>    Project project = projectFactory.createTempProject();
>    WizardCommandController tester = testHarness.createWizardController(JPASetupWizard.class,
>             project.getRoot());
>
>    tester.initialize();
>
>    // Setting UI values
>    tester.setValueFor("jpaVersion", "2.1");
>    tester.setValueFor("provider", provider);
>    tester.setValueFor("container", wildflyContainer);
>
>    tester.next().initialize();
>
>    Assert.assertTrue(tester.isValid());
>    tester.execute();
> }
>
> And now I want to somehow get the dependency facet or some other facet and
> print the content of pom.xml (or the dependencies). How can I do that?
>
> Thanks,
> Ivan
>
> On Wed, Nov 26, 2014 at 10:56 AM, Ivan St. Ivanov <
> ivan.st.ivanov at gmail.com> wrote:
>
>> Hi George,
>>
>> I can work on providing those tests and crafting a solution for the case
>> when the JPA provider is not packed with the target container. Will jump in
>> the IRC channel this week and discuss in more details with you.
>>
>> I see that the JavaEEDefaultContainer implements methods that imply JTA
>> data source. No matter that SAP HCP is built on top of Tomcat, we have our
>> own persistence service, which provides JTA data source. So, generally you
>> are right that I should not extend that abstract class, but in this
>> concrete case with HANA Cloud Platform it is the right thing to do.
>>
>> Cheers,
>> Ivan
>>
>> On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald at redhat.com>
>> wrote:
>>
>>>  Right, I think this makes sense. We might need to add more tests under
>>> these conditions. This area sure needs a bit of improvement.
>>>
>>>  It looks like SAPHanaCloudPlatformContainer shouldn't be extending
>>> JavaEEDefaultContainer, afaik that is only meant to be extended by
>>> implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic,
>>> GlassFish).
>>>
>>>  On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
>>>
>>> Hi George,
>>>
>>>  I was thinking of something general in the area of tying up
>>> somehow (not coupling) the JPA containers and providers. The containers
>>> know very well whether they have JPA support at all or, if they have, what
>>> is their native provider (e.g. Hibernate for Wildfly). So IMHO whenever the
>>> user specifies a container with a provider the setup command should do the
>>> following:
>>>
>>>  1) Validate whether this combination is possible at all (e.g. not sure
>>> what will happen if we specify Wildfly with EclipseLink, at the moment it
>>> fails)
>>> 2) If the current container does not have built-in support for JPA (i.e.
>>> it is based on Tomcat, like SAP HCP) or it supports natively different JPA
>>> provider, then add the listDependencies() content to the pom.xml in the
>>> appropriate scope
>>>
>>>  Something like this. Not sure though how was this whole thing intended
>>> to work: do we need to fully decouple providers and containers in the JPA
>>> addon?
>>>
>>>  Cheers,
>>> Ivan
>>>
>>> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com>
>>> wrote:
>>>
>>>> Hi Ivan,
>>>>
>>>> Yes, that's the idea. It's strange that this method is not being
>>>> called. I'll investigate further.
>>>>
>>>> Another solution would be to create a new Forge's PersistenceProvider
>>>> implementation in a separate addon and select that instead when running
>>>> Jpa:Setup.
>>>>
>>>> Best Regards,
>>>>
>>>> George Gastaldi
>>>>
>>>>
>>>> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>>>> escreveu:
>>>>  >
>>>> > Hi everybody,
>>>> >
>>>> > I have the following usecase. I am developing a web application that
>>>> uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform
>>>> (think of it as Tomcat). Which means that I need the Eclipse Link
>>>> dependencies in the pom.xml in the compile scope. When I generated the
>>>> project and set up Eclipse Link, I got this in the pom:
>>>> >
>>>> >   <dependencies>
>>>> >     <dependency>
>>>> >       <groupId>org.hibernate.javax.persistence</groupId>
>>>> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
>>>> >       <scope>provided</scope>
>>>> >     </dependency>
>>>> >   </dependencies>
>>>> >
>>>> > However, I rather need something like:
>>>> >
>>>> >         <dependency>
>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>> >             <artifactId>javax.persistence</artifactId>
>>>> >         </dependency>
>>>> >         <dependency>
>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>> >             <artifactId>eclipselink</artifactId>
>>>> >         </dependency>
>>>> >
>>>> > I see in
>>>> org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>>>> >
>>>> >
>>>> >    @Override
>>>> >    public List<Dependency> listDependencies()
>>>> >    {
>>>> >       return Arrays.asList((Dependency)
>>>> DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>>>> >                (Dependency)
>>>> DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>>>> >    }
>>>> >
>>>> > So we already have functionality on provider level that knows which
>>>> are the dependencies. However, it seems that this method is not called.
>>>> What was the idea of having it? How can I make sure that the dependencies
>>>> are correctly configured?
>>>> >
>>>> > I think that it has something to do with the type of the container:
>>>> if it is SAP HANA Cloud Platform, then find the dependencies for the JPA
>>>> provider and add them in the default scope of the pom.xml instead of adding
>>>> hibernate-jpa-2.0-api. If it is a full fledged application server, then we
>>>> can go with the API in provided scope. Something like this.
>>>> >
>>>> > WDYT?
>>>> >
>>>> > Thanks,
>>>> > Ivan
>>>>  > _______________________________________________
>>>> > forge-dev mailing list
>>>> > forge-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing listforge-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141127/bbc217f9/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JPASetupDifferentProviderTest.java
Type: text/x-java
Size: 3555 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/forge-dev/attachments/20141127/bbc217f9/attachment-0001.bin 

From ggastald at redhat.com  Thu Nov 27 18:57:50 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Thu, 27 Nov 2014 18:57:50 -0500 (EST)
Subject: [forge-dev] JPA setup command question
In-Reply-To: <CACYLA9FwKhx4oRjkb6ciVNXjfWwUG18cOVYx48VWRL6bFCfKtg@mail.gmail.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
	<5473321F.5090302@redhat.com>
	<CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>
	<CACYLA9G=VnQv8CzcGdYaLLe4d-NtBCMNONWBjbbW23M-MZ9pFQ@mail.gmail.com>
	<0B093E63-9DD8-46E2-B060-CC713BEA0DC3@redhat.com>
	<CACYLA9FwKhx4oRjkb6ciVNXjfWwUG18cOVYx48VWRL6bFCfKtg@mail.gmail.com>
Message-ID: <F86B0179-CE39-438B-85B4-130019F60B29@redhat.com>

I think this involves doing what's defined in https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide 
We should be able to do the necessary changes in the project, however I think we may need to point users to this documentation to handle the changes in the AS itself (or ask Forge to do that itself)



> Em 27/11/2014, ?s 19:58, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
> 
> Thanks George!
> 
> So I have attached the test. You can put it in the javaee addon, under the test folder. It's located in the org.jboss.forge.addon.javaee.jpa.ui.setup package. After you run it, look for the 'dependencies = ' string in the output. I've set it up to use EclipseLink on Wildfly container. I suppose it is not going to work with the JPA API dependency only, is it?
> 
> Cheers,
> Ivan
> 
>> On Thu, Nov 27, 2014 at 11:35 PM, George Gastaldi <ggastald at redhat.com> wrote:
>> Try doing project.getFacet(MavenFacet.class).getModel() and you should have the pom.xml model available
>> 
>> 
>> 
>>> Em 27/11/2014, ?s 19:28, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>> 
>> 
>>> So I was preparing the test. I wanted to create a test case that prints the content of the pom.xml after it invokes the setup command. Here is how I prepare everything:
>>> 
>>> @Inject
>>> private UITestHarness testHarness;
>>> 
>>> @Inject
>>> private ProjectFactory projectFactory;
>>> 
>>> @Inject
>>> private EclipseLinkProvider provider;
>>> 
>>> @Inject
>>> private WildflyContainer wildflyContainer;
>>> @Test
>>> public void testPomXmlContent() throws Exception
>>> {
>>>    Project project = projectFactory.createTempProject();
>>>    WizardCommandController tester = testHarness.createWizardController(JPASetupWizard.class,
>>>             project.getRoot());
>>> 
>>>    tester.initialize();
>>> 
>>>    // Setting UI values
>>>    tester.setValueFor("jpaVersion", "2.1");
>>>    tester.setValueFor("provider", provider);
>>>    tester.setValueFor("container", wildflyContainer);
>>> 
>>>    tester.next().initialize();
>>> 
>>>    Assert.assertTrue(tester.isValid());
>>>    tester.execute();
>>> }
>>> And now I want to somehow get the dependency facet or some other facet and print the content of pom.xml (or the dependencies). How can I do that?
>>> 
>>> Thanks,
>>> Ivan
>>> 
>>>> On Wed, Nov 26, 2014 at 10:56 AM, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> wrote:
>>>> Hi George,
>>>> 
>>>> I can work on providing those tests and crafting a solution for the case when the JPA provider is not packed with the target container. Will jump in the IRC channel this week and discuss in more details with you.
>>>> 
>>>> I see that the JavaEEDefaultContainer implements methods that imply JTA data source. No matter that SAP HCP is built on top of Tomcat, we have our own persistence service, which provides JTA data source. So, generally you are right that I should not extend that abstract class, but in this concrete case with HANA Cloud Platform it is the right thing to do.
>>>> 
>>>> Cheers,
>>>> Ivan
>>>> 
>>>>> On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>> Right, I think this makes sense. We might need to add more tests under these conditions. This area sure needs a bit of improvement.
>>>>> 
>>>>> It looks like SAPHanaCloudPlatformContainer shouldn't be extending JavaEEDefaultContainer, afaik that is only meant to be extended by implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic, GlassFish).
>>>>> 
>>>>>> On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
>>>>>> Hi George,
>>>>>> 
>>>>>> I was thinking of something general in the area of tying up somehow (not coupling) the JPA containers and providers. The containers know very well whether they have JPA support at all or, if they have, what is their native provider (e.g. Hibernate for Wildfly). So IMHO whenever the user specifies a container with a provider the setup command should do the following:
>>>>>> 
>>>>>> 1) Validate whether this combination is possible at all (e.g. not sure what will happen if we specify Wildfly with EclipseLink, at the moment it fails)
>>>>>> 2) If the current container does not have built-in support for JPA (i.e. it is based on Tomcat, like SAP HCP) or it supports natively different JPA provider, then add the listDependencies() content to the pom.xml in the appropriate scope
>>>>>> 
>>>>>> Something like this. Not sure though how was this whole thing intended to work: do we need to fully decouple providers and containers in the JPA addon?
>>>>>> 
>>>>>> Cheers,
>>>>>> Ivan
>>>>>> 
>>>>>> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>>> Hi Ivan,
>>>>>>> 
>>>>>>> Yes, that's the idea. It's strange that this method is not being called. I'll investigate further.
>>>>>>> 
>>>>>>> Another solution would be to create a new Forge's PersistenceProvider implementation in a separate addon and select that instead when running Jpa:Setup.
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> 
>>>>>>> George Gastaldi
>>>>>>> 
>>>>>>> 
>>>>>>> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>>>>>> >
>>>>>>> > Hi everybody,
>>>>>>> >
>>>>>>> > I have the following usecase. I am developing a web application that uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform (think of it as Tomcat). Which means that I need the Eclipse Link dependencies in the pom.xml in the compile scope. When I generated the project and set up Eclipse Link, I got this in the pom:
>>>>>>> >
>>>>>>> >   <dependencies>
>>>>>>> >     <dependency>
>>>>>>> >       <groupId>org.hibernate.javax.persistence</groupId>
>>>>>>> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
>>>>>>> >       <scope>provided</scope>
>>>>>>> >     </dependency>
>>>>>>> >   </dependencies>
>>>>>>> >
>>>>>>> > However, I rather need something like:
>>>>>>> >
>>>>>>> >         <dependency>
>>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>>> >             <artifactId>javax.persistence</artifactId>
>>>>>>> >         </dependency>
>>>>>>> >         <dependency>
>>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>>> >             <artifactId>eclipselink</artifactId>
>>>>>>> >         </dependency>
>>>>>>> >
>>>>>>> > I see in org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>>>>>>> >
>>>>>>> >
>>>>>>> >    @Override
>>>>>>> >    public List<Dependency> listDependencies()
>>>>>>> >    {
>>>>>>> >       return Arrays.asList((Dependency) DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>>>>>>> >                (Dependency) DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>>>>>>> >    }
>>>>>>> >
>>>>>>> > So we already have functionality on provider level that knows which are the dependencies. However, it seems that this method is not called. What was the idea of having it? How can I make sure that the dependencies are correctly configured?
>>>>>>> >
>>>>>>> > I think that it has something to do with the type of the container: if it is SAP HANA Cloud Platform, then find the dependencies for the JPA provider and add them in the default scope of the pom.xml instead of adding                 hibernate-jpa-2.0-api. If it is a full fledged application server, then we can go with the API in provided scope. Something like this.
>>>>>>> >
>>>>>>> > WDYT?
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> > Ivan
>>>>>>> > _______________________________________________
>>>>>>> > forge-dev mailing list
>>>>>>> > forge-dev at lists.jboss.org
>>>>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> forge-dev mailing list
>>>>>>> forge-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> forge-dev mailing list
>>>>>> forge-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> forge-dev mailing list
>>>>> forge-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> 
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>> 
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
> 
> <JPASetupDifferentProviderTest.java>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141127/daa71a58/attachment-0001.html 

From ivan.st.ivanov at gmail.com  Fri Nov 28 04:36:51 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Fri, 28 Nov 2014 11:36:51 +0200
Subject: [forge-dev] JPA setup command question
In-Reply-To: <F86B0179-CE39-438B-85B4-130019F60B29@redhat.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
	<5473321F.5090302@redhat.com>
	<CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>
	<CACYLA9G=VnQv8CzcGdYaLLe4d-NtBCMNONWBjbbW23M-MZ9pFQ@mail.gmail.com>
	<0B093E63-9DD8-46E2-B060-CC713BEA0DC3@redhat.com>
	<CACYLA9FwKhx4oRjkb6ciVNXjfWwUG18cOVYx48VWRL6bFCfKtg@mail.gmail.com>
	<F86B0179-CE39-438B-85B4-130019F60B29@redhat.com>
Message-ID: <CACYLA9E8HW+eoRsEQHU-deORFC0b4MsoJncUnLR7UC_sHia79Q@mail.gmail.com>

Hi George,

This sounds a bit complex :)

In summary we have the following three situations:

1) Application server type of container + primary JPA provider, e.g.
Wildfly + Hibernate JPA
2) Application server type of container + other JPA provider, e.g.Wildfly +
Eclipselink
3) Non application server type of container, i.e. application has to come
packaged with the JPA libraries, e.g. Tomcat

At the moment Forge supports 1). Adding support for 3) would not be very
hard I think. However we should handle 2) case by case I guess. I think
that we definitely need an abstraction in the JPA commands that knows how
to deal with the container+provider combinations.

WDYT?

Cheers,
Ivan

On Fri, Nov 28, 2014 at 1:57 AM, George Gastaldi <ggastald at redhat.com>
wrote:

> I think this involves doing what's defined in
> https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide
> We should be able to do the necessary changes in the project, however I
> think we may need to point users to this documentation to handle the
> changes in the AS itself (or ask Forge to do that itself)
>
>
>
> Em 27/11/2014, ?s 19:58, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
> escreveu:
>
> Thanks George!
>
> So I have attached the test. You can put it in the javaee addon, under the
> test folder. It's located in the org.jboss.forge.addon.javaee.jpa.ui.setup
> package. After you run it, look for the 'dependencies = ' string in the
> output. I've set it up to use EclipseLink on Wildfly container. I suppose
> it is not going to work with the JPA API dependency only, is it?
>
> Cheers,
> Ivan
>
> On Thu, Nov 27, 2014 at 11:35 PM, George Gastaldi <ggastald at redhat.com>
> wrote:
>
>> Try doing project.getFacet(MavenFacet.class).getModel() and you should
>> have the pom.xml model available
>>
>>
>>
>> Em 27/11/2014, ?s 19:28, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>> escreveu:
>>
>> So I was preparing the test. I wanted to create a test case that prints
>> the content of the pom.xml after it invokes the setup command. Here is how
>> I prepare everything:
>>
>> @Inject
>> private UITestHarness testHarness;
>>
>> @Inject
>> private ProjectFactory projectFactory;
>>
>> @Inject
>> private EclipseLinkProvider provider;
>>
>> @Inject
>> private WildflyContainer wildflyContainer;
>>
>> @Test
>> public void testPomXmlContent() throws Exception
>> {
>>    Project project = projectFactory.createTempProject();
>>    WizardCommandController tester = testHarness.createWizardController(JPASetupWizard.class,
>>             project.getRoot());
>>
>>    tester.initialize();
>>
>>    // Setting UI values
>>    tester.setValueFor("jpaVersion", "2.1");
>>    tester.setValueFor("provider", provider);
>>    tester.setValueFor("container", wildflyContainer);
>>
>>    tester.next().initialize();
>>
>>    Assert.assertTrue(tester.isValid());
>>    tester.execute();
>> }
>>
>> And now I want to somehow get the dependency facet or some other facet
>> and print the content of pom.xml (or the dependencies). How can I do that?
>>
>> Thanks,
>> Ivan
>>
>> On Wed, Nov 26, 2014 at 10:56 AM, Ivan St. Ivanov <
>> ivan.st.ivanov at gmail.com> wrote:
>>
>>> Hi George,
>>>
>>> I can work on providing those tests and crafting a solution for the case
>>> when the JPA provider is not packed with the target container. Will jump in
>>> the IRC channel this week and discuss in more details with you.
>>>
>>> I see that the JavaEEDefaultContainer implements methods that imply JTA
>>> data source. No matter that SAP HCP is built on top of Tomcat, we have our
>>> own persistence service, which provides JTA data source. So, generally you
>>> are right that I should not extend that abstract class, but in this
>>> concrete case with HANA Cloud Platform it is the right thing to do.
>>>
>>> Cheers,
>>> Ivan
>>>
>>> On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald at redhat.com>
>>> wrote:
>>>
>>>>  Right, I think this makes sense. We might need to add more tests
>>>> under these conditions. This area sure needs a bit of improvement.
>>>>
>>>>  It looks like SAPHanaCloudPlatformContainer shouldn't be extending
>>>> JavaEEDefaultContainer, afaik that is only meant to be extended by
>>>> implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic,
>>>> GlassFish).
>>>>
>>>>  On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
>>>>
>>>> Hi George,
>>>>
>>>>  I was thinking of something general in the area of tying up
>>>> somehow (not coupling) the JPA containers and providers. The containers
>>>> know very well whether they have JPA support at all or, if they have, what
>>>> is their native provider (e.g. Hibernate for Wildfly). So IMHO whenever the
>>>> user specifies a container with a provider the setup command should do the
>>>> following:
>>>>
>>>>  1) Validate whether this combination is possible at all (e.g. not
>>>> sure what will happen if we specify Wildfly with EclipseLink, at the moment
>>>> it fails)
>>>> 2) If the current container does not have built-in support for JPA
>>>> (i.e. it is based on Tomcat, like SAP HCP) or it supports natively
>>>> different JPA provider, then add the listDependencies() content to the
>>>> pom.xml in the appropriate scope
>>>>
>>>>  Something like this. Not sure though how was this whole thing
>>>> intended to work: do we need to fully decouple providers and containers in
>>>> the JPA addon?
>>>>
>>>>  Cheers,
>>>> Ivan
>>>>
>>>> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi Ivan,
>>>>>
>>>>> Yes, that's the idea. It's strange that this method is not being
>>>>> called. I'll investigate further.
>>>>>
>>>>> Another solution would be to create a new Forge's PersistenceProvider
>>>>> implementation in a separate addon and select that instead when running
>>>>> Jpa:Setup.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> George Gastaldi
>>>>>
>>>>>
>>>>> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>>>>> escreveu:
>>>>>  >
>>>>> > Hi everybody,
>>>>> >
>>>>> > I have the following usecase. I am developing a web application that
>>>>> uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform
>>>>> (think of it as Tomcat). Which means that I need the Eclipse Link
>>>>> dependencies in the pom.xml in the compile scope. When I generated the
>>>>> project and set up Eclipse Link, I got this in the pom:
>>>>> >
>>>>> >   <dependencies>
>>>>> >     <dependency>
>>>>> >       <groupId>org.hibernate.javax.persistence</groupId>
>>>>> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
>>>>> >       <scope>provided</scope>
>>>>> >     </dependency>
>>>>> >   </dependencies>
>>>>> >
>>>>> > However, I rather need something like:
>>>>> >
>>>>> >         <dependency>
>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>> >             <artifactId>javax.persistence</artifactId>
>>>>> >         </dependency>
>>>>> >         <dependency>
>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>> >             <artifactId>eclipselink</artifactId>
>>>>> >         </dependency>
>>>>> >
>>>>> > I see in
>>>>> org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>>>>> >
>>>>> >
>>>>> >    @Override
>>>>> >    public List<Dependency> listDependencies()
>>>>> >    {
>>>>> >       return Arrays.asList((Dependency)
>>>>> DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>>>>> >                (Dependency)
>>>>> DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>>>>> >    }
>>>>> >
>>>>> > So we already have functionality on provider level that knows which
>>>>> are the dependencies. However, it seems that this method is not called.
>>>>> What was the idea of having it? How can I make sure that the dependencies
>>>>> are correctly configured?
>>>>> >
>>>>> > I think that it has something to do with the type of the container:
>>>>> if it is SAP HANA Cloud Platform, then find the dependencies for the JPA
>>>>> provider and add them in the default scope of the pom.xml instead of adding
>>>>> hibernate-jpa-2.0-api. If it is a full fledged application server, then we
>>>>> can go with the API in provided scope. Something like this.
>>>>> >
>>>>> > WDYT?
>>>>> >
>>>>> > Thanks,
>>>>> > Ivan
>>>>>  > _______________________________________________
>>>>> > forge-dev mailing list
>>>>> > forge-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>
>>>>> _______________________________________________
>>>>> forge-dev mailing list
>>>>> forge-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> forge-dev mailing listforge-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>
>>>
>>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
> <JPASetupDifferentProviderTest.java>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141128/0f5df2b6/attachment-0001.html 

From ggastald at redhat.com  Fri Nov 28 07:34:30 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Fri, 28 Nov 2014 07:34:30 -0500 (EST)
Subject: [forge-dev] JPA setup command question
In-Reply-To: <CACYLA9E8HW+eoRsEQHU-deORFC0b4MsoJncUnLR7UC_sHia79Q@mail.gmail.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
	<5473321F.5090302@redhat.com>
	<CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>
	<CACYLA9G=VnQv8CzcGdYaLLe4d-NtBCMNONWBjbbW23M-MZ9pFQ@mail.gmail.com>
	<0B093E63-9DD8-46E2-B060-CC713BEA0DC3@redhat.com>
	<CACYLA9FwKhx4oRjkb6ciVNXjfWwUG18cOVYx48VWRL6bFCfKtg@mail.gmail.com>
	<F86B0179-CE39-438B-85B4-130019F60B29@redhat.com>
	<CACYLA9E8HW+eoRsEQHU-deORFC0b4MsoJncUnLR7UC_sHia79Q@mail.gmail.com>
Message-ID: <9B818D2C-C569-4D3F-BF92-6F6BABABF81F@redhat.com>

Yes, I agree. 

However I wonder if these combinations wouldn't become too hard to maintain? This looks like something that could be implemented using a rule engine, like Drools. 

Thoughts? 


> Em 28/11/2014, ?s 07:37, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
> 
> Hi George,
> 
> This sounds a bit complex :)
> 
> In summary we have the following three situations:
> 
> 1) Application server type of container + primary JPA provider, e.g. Wildfly + Hibernate JPA
> 2) Application server type of container + other JPA provider, e.g.Wildfly + Eclipselink
> 3) Non application server type of container, i.e. application has to come packaged with the JPA libraries, e.g. Tomcat
> 
> At the moment Forge supports 1). Adding support for 3) would not be very hard I think. However we should handle 2) case by case I guess. I think that we definitely need an abstraction in the JPA commands that knows how to deal with the container+provider combinations.
> 
> WDYT?
> 
> Cheers,
> Ivan
> 
>> On Fri, Nov 28, 2014 at 1:57 AM, George Gastaldi <ggastald at redhat.com> wrote:
>> I think this involves doing what's defined in https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide 
>> We should be able to do the necessary changes in the project, however I think we may need to point users to this documentation to handle the changes in the AS itself (or ask Forge to do that itself)
>> 
>> 
>> 
>>> Em 27/11/2014, ?s 19:58, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>> 
>> 
>>> Thanks George!
>>> 
>>> So I have attached the test. You can put it in the javaee addon, under the test folder. It's located in the org.jboss.forge.addon.javaee.jpa.ui.setup package. After you run it, look for the 'dependencies = ' string in the output. I've set it up to use EclipseLink on Wildfly container. I suppose it is not going to work with the JPA API dependency only, is it?
>>> 
>>> Cheers,
>>> Ivan
>>> 
>>>> On Thu, Nov 27, 2014 at 11:35 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>> Try doing project.getFacet(MavenFacet.class).getModel() and you should have the pom.xml model available
>>>> 
>>>> 
>>>> 
>>>>> Em 27/11/2014, ?s 19:28, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>>>> 
>>>> 
>>>>> So I was preparing the test. I wanted to create a test case that prints the content of the pom.xml after it invokes the setup command. Here is how I prepare everything:
>>>>> 
>>>>> @Inject
>>>>> private UITestHarness testHarness;
>>>>> 
>>>>> @Inject
>>>>> private ProjectFactory projectFactory;
>>>>> 
>>>>> @Inject
>>>>> private EclipseLinkProvider provider;
>>>>> 
>>>>> @Inject
>>>>> private WildflyContainer wildflyContainer;
>>>>> @Test
>>>>> public void testPomXmlContent() throws Exception
>>>>> {
>>>>>    Project project = projectFactory.createTempProject();
>>>>>    WizardCommandController tester = testHarness.createWizardController(JPASetupWizard.class,
>>>>>             project.getRoot());
>>>>> 
>>>>>    tester.initialize();
>>>>> 
>>>>>    // Setting UI values
>>>>>    tester.setValueFor("jpaVersion", "2.1");
>>>>>    tester.setValueFor("provider", provider);
>>>>>    tester.setValueFor("container", wildflyContainer);
>>>>> 
>>>>>    tester.next().initialize();
>>>>> 
>>>>>    Assert.assertTrue(tester.isValid());
>>>>>    tester.execute();
>>>>> }
>>>>> And now I want to somehow get the dependency facet or some other facet and print the content of pom.xml (or the dependencies). How can I do that?
>>>>> 
>>>>> Thanks,
>>>>> Ivan
>>>>> 
>>>>>> On Wed, Nov 26, 2014 at 10:56 AM, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> wrote:
>>>>>> Hi George,
>>>>>> 
>>>>>> I can work on providing those tests and crafting a solution for the case when the JPA provider is not packed with the target container. Will jump in the IRC channel this week and discuss in more details with you.
>>>>>> 
>>>>>> I see that the JavaEEDefaultContainer implements methods that imply JTA data source. No matter that SAP HCP is built on top of Tomcat, we have our own persistence service, which provides JTA data source. So, generally you are right that I should not extend that abstract class, but in this concrete case with HANA Cloud Platform it is the right thing to do.
>>>>>> 
>>>>>> Cheers,
>>>>>> Ivan
>>>>>> 
>>>>>>> On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>>> Right, I think this makes sense. We might need to add more tests under these conditions. This area sure needs a bit of improvement.
>>>>>>> 
>>>>>>> It looks like SAPHanaCloudPlatformContainer shouldn't be extending JavaEEDefaultContainer, afaik that is only meant to be extended by implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic, GlassFish).
>>>>>>> 
>>>>>>>> On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
>>>>>>>> Hi George,
>>>>>>>> 
>>>>>>>> I was thinking of something general in the area of tying up somehow (not coupling) the JPA containers and providers. The containers know very well whether they have JPA support at all or, if they have, what is their native provider (e.g. Hibernate for Wildfly). So IMHO whenever the user specifies a container with a provider the setup command should do the following:
>>>>>>>> 
>>>>>>>> 1) Validate whether this combination is possible at all (e.g. not sure what will happen if we specify Wildfly with EclipseLink, at the moment it fails)
>>>>>>>> 2) If the current container does not have built-in support for JPA (i.e. it is based on Tomcat, like SAP HCP) or it supports natively different JPA provider, then add the listDependencies() content to the pom.xml in the appropriate scope
>>>>>>>> 
>>>>>>>> Something like this. Not sure though how was this whole thing intended to work: do we need to fully decouple providers and containers in the JPA addon?
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Ivan
>>>>>>>> 
>>>>>>>> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>>>>> Hi Ivan,
>>>>>>>>> 
>>>>>>>>> Yes, that's the idea. It's strange that this method is not being called. I'll investigate further.
>>>>>>>>> 
>>>>>>>>> Another solution would be to create a new Forge's PersistenceProvider implementation in a separate addon and select that instead when running Jpa:Setup.
>>>>>>>>> 
>>>>>>>>> Best Regards,
>>>>>>>>> 
>>>>>>>>> George Gastaldi
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>>>>>>>> >
>>>>>>>>> > Hi everybody,
>>>>>>>>> >
>>>>>>>>> > I have the following usecase. I am developing a web application that uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform (think of it as Tomcat). Which means that I need the Eclipse Link dependencies in the pom.xml in the compile scope. When I generated the project and set up Eclipse Link, I got this in the pom:
>>>>>>>>> >
>>>>>>>>> >   <dependencies>
>>>>>>>>> >     <dependency>
>>>>>>>>> >       <groupId>org.hibernate.javax.persistence</groupId>
>>>>>>>>> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
>>>>>>>>> >       <scope>provided</scope>
>>>>>>>>> >     </dependency>
>>>>>>>>> >   </dependencies>
>>>>>>>>> >
>>>>>>>>> > However, I rather need something like:
>>>>>>>>> >
>>>>>>>>> >         <dependency>
>>>>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>>>>> >             <artifactId>javax.persistence</artifactId>
>>>>>>>>> >         </dependency>
>>>>>>>>> >         <dependency>
>>>>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>>>>> >             <artifactId>eclipselink</artifactId>
>>>>>>>>> >         </dependency>
>>>>>>>>> >
>>>>>>>>> > I see in org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >    @Override
>>>>>>>>> >    public List<Dependency> listDependencies()
>>>>>>>>> >    {
>>>>>>>>> >       return Arrays.asList((Dependency) DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>>>>>>>>> >                (Dependency) DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>>>>>>>>> >    }
>>>>>>>>> >
>>>>>>>>> > So we already have functionality on provider level that knows which are the dependencies. However, it seems that this method is not called. What was the idea of having it? How can I make sure that the dependencies are correctly configured?
>>>>>>>>> >
>>>>>>>>> > I think that it has something to do with the type of the container: if it is SAP HANA Cloud Platform, then find the dependencies for the JPA provider and add them in the default scope of the pom.xml instead of adding hibernate-jpa-2.0-api. If it is a full fledged application server, then we can go with the API in provided scope. Something like this.
>>>>>>>>> >
>>>>>>>>> > WDYT?
>>>>>>>>> >
>>>>>>>>> > Thanks,
>>>>>>>>> > Ivan
>>>>>>>>> > _______________________________________________
>>>>>>>>> > forge-dev mailing list
>>>>>>>>> > forge-dev at lists.jboss.org
>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> forge-dev mailing list
>>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> forge-dev mailing list
>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> forge-dev mailing list
>>>>>>> forge-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> forge-dev mailing list
>>>>> forge-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>> 
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> 
>>> <JPASetupDifferentProviderTest.java>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>> 
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
> 
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141128/ee15b427/attachment-0001.html 

From ivan.st.ivanov at gmail.com  Fri Nov 28 07:38:16 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Fri, 28 Nov 2014 14:38:16 +0200
Subject: [forge-dev] JPA setup command question
In-Reply-To: <9B818D2C-C569-4D3F-BF92-6F6BABABF81F@redhat.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
	<5473321F.5090302@redhat.com>
	<CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>
	<CACYLA9G=VnQv8CzcGdYaLLe4d-NtBCMNONWBjbbW23M-MZ9pFQ@mail.gmail.com>
	<0B093E63-9DD8-46E2-B060-CC713BEA0DC3@redhat.com>
	<CACYLA9FwKhx4oRjkb6ciVNXjfWwUG18cOVYx48VWRL6bFCfKtg@mail.gmail.com>
	<F86B0179-CE39-438B-85B4-130019F60B29@redhat.com>
	<CACYLA9E8HW+eoRsEQHU-deORFC0b4MsoJncUnLR7UC_sHia79Q@mail.gmail.com>
	<9B818D2C-C569-4D3F-BF92-6F6BABABF81F@redhat.com>
Message-ID: <CACYLA9G6mM_smOeSwdza+2Hdt2Am9v5K5ftrV0Ky0HDmck6L+Q@mail.gmail.com>

I don't have any experience with Drools or rules engines per se. I may try
to hack something and based on that we can think whether it is worth the
effort. OK?

On Fri, Nov 28, 2014 at 2:34 PM, George Gastaldi <ggastald at redhat.com>
wrote:

> Yes, I agree.
>
> However I wonder if these combinations wouldn't become too hard to
> maintain? This looks like something that could be implemented using a rule
> engine, like Drools.
>
> Thoughts?
>
>
> Em 28/11/2014, ?s 07:37, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
> escreveu:
>
> Hi George,
>
> This sounds a bit complex :)
>
> In summary we have the following three situations:
>
> 1) Application server type of container + primary JPA provider, e.g.
> Wildfly + Hibernate JPA
> 2) Application server type of container + other JPA provider, e.g.Wildfly
> + Eclipselink
> 3) Non application server type of container, i.e. application has to come
> packaged with the JPA libraries, e.g. Tomcat
>
> At the moment Forge supports 1). Adding support for 3) would not be very
> hard I think. However we should handle 2) case by case I guess. I think
> that we definitely need an abstraction in the JPA commands that knows how
> to deal with the container+provider combinations.
>
> WDYT?
>
> Cheers,
> Ivan
>
> On Fri, Nov 28, 2014 at 1:57 AM, George Gastaldi <ggastald at redhat.com>
> wrote:
>
>> I think this involves doing what's defined in
>> https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide
>> We should be able to do the necessary changes in the project, however I
>> think we may need to point users to this documentation to handle the
>> changes in the AS itself (or ask Forge to do that itself)
>>
>>
>>
>> Em 27/11/2014, ?s 19:58, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>> escreveu:
>>
>> Thanks George!
>>
>> So I have attached the test. You can put it in the javaee addon, under
>> the test folder. It's located in
>> the org.jboss.forge.addon.javaee.jpa.ui.setup package. After you run it,
>> look for the 'dependencies = ' string in the output. I've set it up to use
>> EclipseLink on Wildfly container. I suppose it is not going to work with
>> the JPA API dependency only, is it?
>>
>> Cheers,
>> Ivan
>>
>> On Thu, Nov 27, 2014 at 11:35 PM, George Gastaldi <ggastald at redhat.com>
>> wrote:
>>
>>> Try doing project.getFacet(MavenFacet.class).getModel() and you should
>>> have the pom.xml model available
>>>
>>>
>>>
>>> Em 27/11/2014, ?s 19:28, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>>> escreveu:
>>>
>>> So I was preparing the test. I wanted to create a test case that prints
>>> the content of the pom.xml after it invokes the setup command. Here is how
>>> I prepare everything:
>>>
>>> @Inject
>>> private UITestHarness testHarness;
>>>
>>> @Inject
>>> private ProjectFactory projectFactory;
>>>
>>> @Inject
>>> private EclipseLinkProvider provider;
>>>
>>> @Inject
>>> private WildflyContainer wildflyContainer;
>>>
>>> @Test
>>> public void testPomXmlContent() throws Exception
>>> {
>>>    Project project = projectFactory.createTempProject();
>>>    WizardCommandController tester = testHarness.createWizardController(JPASetupWizard.class,
>>>             project.getRoot());
>>>
>>>    tester.initialize();
>>>
>>>    // Setting UI values
>>>    tester.setValueFor("jpaVersion", "2.1");
>>>    tester.setValueFor("provider", provider);
>>>    tester.setValueFor("container", wildflyContainer);
>>>
>>>    tester.next().initialize();
>>>
>>>    Assert.assertTrue(tester.isValid());
>>>    tester.execute();
>>> }
>>>
>>> And now I want to somehow get the dependency facet or some other facet
>>> and print the content of pom.xml (or the dependencies). How can I do that?
>>>
>>> Thanks,
>>> Ivan
>>>
>>> On Wed, Nov 26, 2014 at 10:56 AM, Ivan St. Ivanov <
>>> ivan.st.ivanov at gmail.com> wrote:
>>>
>>>> Hi George,
>>>>
>>>> I can work on providing those tests and crafting a solution for the
>>>> case when the JPA provider is not packed with the target container. Will
>>>> jump in the IRC channel this week and discuss in more details with you.
>>>>
>>>> I see that the JavaEEDefaultContainer implements methods that imply JTA
>>>> data source. No matter that SAP HCP is built on top of Tomcat, we have our
>>>> own persistence service, which provides JTA data source. So, generally you
>>>> are right that I should not extend that abstract class, but in this
>>>> concrete case with HANA Cloud Platform it is the right thing to do.
>>>>
>>>> Cheers,
>>>> Ivan
>>>>
>>>> On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald at redhat.com>
>>>> wrote:
>>>>
>>>>>  Right, I think this makes sense. We might need to add more tests
>>>>> under these conditions. This area sure needs a bit of improvement.
>>>>>
>>>>>  It looks like SAPHanaCloudPlatformContainer shouldn't be extending
>>>>> JavaEEDefaultContainer, afaik that is only meant to be extended by
>>>>> implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic,
>>>>> GlassFish).
>>>>>
>>>>>  On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
>>>>>
>>>>> Hi George,
>>>>>
>>>>>  I was thinking of something general in the area of tying up
>>>>> somehow (not coupling) the JPA containers and providers. The containers
>>>>> know very well whether they have JPA support at all or, if they have, what
>>>>> is their native provider (e.g. Hibernate for Wildfly). So IMHO whenever the
>>>>> user specifies a container with a provider the setup command should do the
>>>>> following:
>>>>>
>>>>>  1) Validate whether this combination is possible at all (e.g. not
>>>>> sure what will happen if we specify Wildfly with EclipseLink, at the moment
>>>>> it fails)
>>>>> 2) If the current container does not have built-in support for JPA
>>>>> (i.e. it is based on Tomcat, like SAP HCP) or it supports natively
>>>>> different JPA provider, then add the listDependencies() content to the
>>>>> pom.xml in the appropriate scope
>>>>>
>>>>>  Something like this. Not sure though how was this whole thing
>>>>> intended to work: do we need to fully decouple providers and containers in
>>>>> the JPA addon?
>>>>>
>>>>>  Cheers,
>>>>> Ivan
>>>>>
>>>>> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Ivan,
>>>>>>
>>>>>> Yes, that's the idea. It's strange that this method is not being
>>>>>> called. I'll investigate further.
>>>>>>
>>>>>> Another solution would be to create a new Forge's PersistenceProvider
>>>>>> implementation in a separate addon and select that instead when running
>>>>>> Jpa:Setup.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> George Gastaldi
>>>>>>
>>>>>>
>>>>>> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>>>>>> escreveu:
>>>>>>  >
>>>>>> > Hi everybody,
>>>>>> >
>>>>>> > I have the following usecase. I am developing a web application
>>>>>> that uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud
>>>>>> Platform (think of it as Tomcat). Which means that I need the Eclipse Link
>>>>>> dependencies in the pom.xml in the compile scope. When I generated the
>>>>>> project and set up Eclipse Link, I got this in the pom:
>>>>>> >
>>>>>> >   <dependencies>
>>>>>> >     <dependency>
>>>>>> >       <groupId>org.hibernate.javax.persistence</groupId>
>>>>>> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
>>>>>> >       <scope>provided</scope>
>>>>>> >     </dependency>
>>>>>> >   </dependencies>
>>>>>> >
>>>>>> > However, I rather need something like:
>>>>>> >
>>>>>> >         <dependency>
>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>> >             <artifactId>javax.persistence</artifactId>
>>>>>> >         </dependency>
>>>>>> >         <dependency>
>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>> >             <artifactId>eclipselink</artifactId>
>>>>>> >         </dependency>
>>>>>> >
>>>>>> > I see in
>>>>>> org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>>>>>> >
>>>>>> >
>>>>>> >    @Override
>>>>>> >    public List<Dependency> listDependencies()
>>>>>> >    {
>>>>>> >       return Arrays.asList((Dependency)
>>>>>> DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>>>>>> >                (Dependency)
>>>>>> DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>>>>>> >    }
>>>>>> >
>>>>>> > So we already have functionality on provider level that knows which
>>>>>> are the dependencies. However, it seems that this method is not called.
>>>>>> What was the idea of having it? How can I make sure that the dependencies
>>>>>> are correctly configured?
>>>>>> >
>>>>>> > I think that it has something to do with the type of the container:
>>>>>> if it is SAP HANA Cloud Platform, then find the dependencies for the JPA
>>>>>> provider and add them in the default scope of the pom.xml instead of adding
>>>>>> hibernate-jpa-2.0-api. If it is a full fledged application server, then we
>>>>>> can go with the API in provided scope. Something like this.
>>>>>> >
>>>>>> > WDYT?
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Ivan
>>>>>>  > _______________________________________________
>>>>>> > forge-dev mailing list
>>>>>> > forge-dev at lists.jboss.org
>>>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> forge-dev mailing list
>>>>>> forge-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> forge-dev mailing listforge-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> forge-dev mailing list
>>>>> forge-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>> <JPASetupDifferentProviderTest.java>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141128/30573110/attachment-0001.html 

From ggastald at redhat.com  Fri Nov 28 07:48:54 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Fri, 28 Nov 2014 07:48:54 -0500 (EST)
Subject: [forge-dev] JPA setup command question
In-Reply-To: <CACYLA9G6mM_smOeSwdza+2Hdt2Am9v5K5ftrV0Ky0HDmck6L+Q@mail.gmail.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
	<5473321F.5090302@redhat.com>
	<CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>
	<CACYLA9G=VnQv8CzcGdYaLLe4d-NtBCMNONWBjbbW23M-MZ9pFQ@mail.gmail.com>
	<0B093E63-9DD8-46E2-B060-CC713BEA0DC3@redhat.com>
	<CACYLA9FwKhx4oRjkb6ciVNXjfWwUG18cOVYx48VWRL6bFCfKtg@mail.gmail.com>
	<F86B0179-CE39-438B-85B4-130019F60B29@redhat.com>
	<CACYLA9E8HW+eoRsEQHU-deORFC0b4MsoJncUnLR7UC_sHia79Q@mail.gmail.com>
	<9B818D2C-C569-4D3F-BF92-6F6BABABF81F@redhat.com>
	<CACYLA9G6mM_smOeSwdza+2Hdt2Am9v5K5ftrV0Ky0HDmck6L+Q@mail.gmail.com>
Message-ID: <EC64AE5E-F71E-4151-BD1A-1F6C138700D4@redhat.com>

Sounds good



> Em 28/11/2014, ?s 10:38, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
> 
> I don't have any experience with Drools or rules engines per se. I may try to hack something and based on that we can think whether it is worth the effort. OK?
> 
>> On Fri, Nov 28, 2014 at 2:34 PM, George Gastaldi <ggastald at redhat.com> wrote:
>> Yes, I agree. 
>> 
>> However I wonder if these combinations wouldn't become too hard to maintain? This looks like something that could be implemented using a rule engine, like Drools. 
>> 
>> Thoughts? 
>> 
>> 
>>> Em 28/11/2014, ?s 07:37, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>> 
>> 
>>> Hi George,
>>> 
>>> This sounds a bit complex :)
>>> 
>>> In summary we have the following three situations:
>>> 
>>> 1) Application server type of container + primary JPA provider, e.g. Wildfly + Hibernate JPA
>>> 2) Application server type of container + other JPA provider, e.g.Wildfly + Eclipselink
>>> 3) Non application server type of container, i.e. application has to come packaged with the JPA libraries, e.g. Tomcat
>>> 
>>> At the moment Forge supports 1). Adding support for 3) would not be very hard I think. However we should handle 2) case by case I guess. I think that we definitely need an abstraction in the JPA commands that knows how to deal with the container+provider combinations.
>>> 
>>> WDYT?
>>> 
>>> Cheers,
>>> Ivan
>>> 
>>>> On Fri, Nov 28, 2014 at 1:57 AM, George Gastaldi <ggastald at redhat.com> wrote:
>>>> I think this involves doing what's defined in https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide 
>>>> We should be able to do the necessary changes in the project, however I think we may need to point users to this documentation to handle the changes in the AS itself (or ask Forge to do that itself)
>>>> 
>>>> 
>>>> 
>>>>> Em 27/11/2014, ?s 19:58, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>>>> 
>>>> 
>>>>> Thanks George!
>>>>> 
>>>>> So I have attached the test. You can put it in the javaee addon, under the test folder. It's located in the org.jboss.forge.addon.javaee.jpa.ui.setup package. After you run it, look for the 'dependencies = ' string in the output. I've set it up to use EclipseLink on Wildfly container. I suppose it is not going to work with the JPA API dependency only, is it?
>>>>> 
>>>>> Cheers,
>>>>> Ivan
>>>>> 
>>>>>> On Thu, Nov 27, 2014 at 11:35 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>> Try doing project.getFacet(MavenFacet.class).getModel() and you should have the pom.xml model available
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Em 27/11/2014, ?s 19:28, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>>>>>> 
>>>>>> 
>>>>>>> So I was preparing the test. I wanted to create a test case that prints the content of the pom.xml after it invokes the setup command. Here is how I prepare everything:
>>>>>>> 
>>>>>>> @Inject
>>>>>>> private UITestHarness testHarness;
>>>>>>> 
>>>>>>> @Inject
>>>>>>> private ProjectFactory projectFactory;
>>>>>>> 
>>>>>>> @Inject
>>>>>>> private EclipseLinkProvider provider;
>>>>>>> 
>>>>>>> @Inject
>>>>>>> private WildflyContainer wildflyContainer;
>>>>>>> @Test
>>>>>>> public void testPomXmlContent() throws Exception
>>>>>>> {
>>>>>>>    Project project = projectFactory.createTempProject();
>>>>>>>    WizardCommandController tester = testHarness.createWizardController(JPASetupWizard.class,
>>>>>>>             project.getRoot());
>>>>>>> 
>>>>>>>    tester.initialize();
>>>>>>> 
>>>>>>>    // Setting UI values
>>>>>>>    tester.setValueFor("jpaVersion", "2.1");
>>>>>>>    tester.setValueFor("provider", provider);
>>>>>>>    tester.setValueFor("container", wildflyContainer);
>>>>>>> 
>>>>>>>    tester.next().initialize();
>>>>>>> 
>>>>>>>    Assert.assertTrue(tester.isValid());
>>>>>>>    tester.execute();
>>>>>>> }
>>>>>>> And now I want to somehow get the dependency facet or some other facet and print the content of pom.xml (or the dependencies). How can I do that?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Ivan
>>>>>>> 
>>>>>>>> On Wed, Nov 26, 2014 at 10:56 AM, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> wrote:
>>>>>>>> Hi George,
>>>>>>>> 
>>>>>>>> I can work on providing those tests and crafting a solution for the case when the JPA provider is not packed with the target container. Will jump in the IRC channel this week and discuss in more details with you.
>>>>>>>> 
>>>>>>>> I see that the JavaEEDefaultContainer implements methods that imply JTA data source. No matter that SAP HCP is built on top of Tomcat, we have our own persistence service, which provides JTA data source. So, generally you are right that I should not extend that abstract class, but in this concrete case with HANA Cloud Platform it is the right thing to do.
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Ivan
>>>>>>>> 
>>>>>>>>> On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>>>>> Right, I think this makes sense. We might need to add more tests under these conditions. This area sure needs a bit of improvement.
>>>>>>>>> 
>>>>>>>>> It looks like SAPHanaCloudPlatformContainer shouldn't be extending JavaEEDefaultContainer, afaik that is only meant to be extended by implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic, GlassFish).
>>>>>>>>> 
>>>>>>>>>> On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
>>>>>>>>>> Hi George,
>>>>>>>>>> 
>>>>>>>>>> I was thinking of something general in the area of tying up somehow (not coupling) the JPA containers and providers. The containers know very well whether they have JPA support at all or, if they have, what is their native provider (e.g. Hibernate for Wildfly). So IMHO whenever the user specifies a container with a provider the setup command should do the following:
>>>>>>>>>> 
>>>>>>>>>> 1) Validate whether this combination is possible at all (e.g. not sure what will happen if we specify Wildfly with EclipseLink, at the moment it fails)
>>>>>>>>>> 2) If the current container does not have built-in support for JPA (i.e. it is based on Tomcat, like SAP HCP) or it supports natively different JPA provider, then add the listDependencies() content to the pom.xml in the appropriate scope
>>>>>>>>>> 
>>>>>>>>>> Something like this. Not sure though how was this whole thing intended to work: do we need to fully decouple providers and containers in the JPA addon?
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> Ivan
>>>>>>>>>> 
>>>>>>>>>>> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>>>>>>> Hi Ivan,
>>>>>>>>>>> 
>>>>>>>>>>> Yes, that's the idea. It's strange that this method is not being called. I'll investigate further.
>>>>>>>>>>> 
>>>>>>>>>>> Another solution would be to create a new Forge's PersistenceProvider implementation in a separate addon and             select that instead when running Jpa:Setup.
>>>>>>>>>>> 
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> 
>>>>>>>>>>> George Gastaldi
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>>>>>>>>>> >
>>>>>>>>>>> > Hi everybody,
>>>>>>>>>>> >
>>>>>>>>>>> > I have the following usecase. I am developing a web application that uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform (think of it as Tomcat). Which means that I need the Eclipse Link dependencies in the pom.xml in the compile scope. When I generated the project and set up Eclipse Link, I got this in the pom:
>>>>>>>>>>> >
>>>>>>>>>>> >   <dependencies>
>>>>>>>>>>> >     <dependency>
>>>>>>>>>>> >       <groupId>org.hibernate.javax.persistence</groupId>
>>>>>>>>>>> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
>>>>>>>>>>> >       <scope>provided</scope>
>>>>>>>>>>> >     </dependency>
>>>>>>>>>>> >   </dependencies>
>>>>>>>>>>> >
>>>>>>>>>>> > However, I rather need something like:
>>>>>>>>>>> >
>>>>>>>>>>> >         <dependency>
>>>>>>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>>>>>>> >             <artifactId>javax.persistence</artifactId>
>>>>>>>>>>> >         </dependency>
>>>>>>>>>>> >         <dependency>
>>>>>>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>>>>>>> >             <artifactId>eclipselink</artifactId>
>>>>>>>>>>> >         </dependency>
>>>>>>>>>>> >
>>>>>>>>>>> > I see in org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >    @Override
>>>>>>>>>>> >    public List<Dependency> listDependencies()
>>>>>>>>>>> >    {
>>>>>>>>>>> >       return Arrays.asList((Dependency) DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>>>>>>>>>>> >                (Dependency) DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>>>>>>>>>>> >    }
>>>>>>>>>>> >
>>>>>>>>>>> > So we already have functionality on provider level that knows which are the dependencies. However, it seems that this method is not called. What was the idea of having it? How can I make sure that the dependencies are correctly configured?
>>>>>>>>>>> >
>>>>>>>>>>> > I think that it has something to do with the type of the container: if it is SAP HANA Cloud Platform, then find the dependencies for the JPA provider and add them in the default scope of the pom.xml instead of adding hibernate-jpa-2.0-api. If it is a full fledged application server, then we can go with the API in provided scope. Something like this.
>>>>>>>>>>> >
>>>>>>>>>>> > WDYT?
>>>>>>>>>>> >
>>>>>>>>>>> > Thanks,
>>>>>>>>>>> > Ivan
>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>> > forge-dev mailing list
>>>>>>>>>>> > forge-dev at lists.jboss.org
>>>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> forge-dev mailing list
>>>>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> forge-dev mailing list
>>>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> forge-dev mailing list
>>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> forge-dev mailing list
>>>>>>> forge-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>> 
>>>>>> _______________________________________________
>>>>>> forge-dev mailing list
>>>>>> forge-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>> 
>>>>> <JPASetupDifferentProviderTest.java>
>>>>> _______________________________________________
>>>>> forge-dev mailing list
>>>>> forge-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>> 
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> 
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>> 
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
> 
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141128/5c5afe71/attachment-0001.html 

From ivan.st.ivanov at gmail.com  Sun Nov 30 16:00:03 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Sun, 30 Nov 2014 23:00:03 +0200
Subject: [forge-dev] JPA setup command question
In-Reply-To: <EC64AE5E-F71E-4151-BD1A-1F6C138700D4@redhat.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
	<5473321F.5090302@redhat.com>
	<CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>
	<CACYLA9G=VnQv8CzcGdYaLLe4d-NtBCMNONWBjbbW23M-MZ9pFQ@mail.gmail.com>
	<0B093E63-9DD8-46E2-B060-CC713BEA0DC3@redhat.com>
	<CACYLA9FwKhx4oRjkb6ciVNXjfWwUG18cOVYx48VWRL6bFCfKtg@mail.gmail.com>
	<F86B0179-CE39-438B-85B4-130019F60B29@redhat.com>
	<CACYLA9E8HW+eoRsEQHU-deORFC0b4MsoJncUnLR7UC_sHia79Q@mail.gmail.com>
	<9B818D2C-C569-4D3F-BF92-6F6BABABF81F@redhat.com>
	<CACYLA9G6mM_smOeSwdza+2Hdt2Am9v5K5ftrV0Ky0HDmck6L+Q@mail.gmail.com>
	<EC64AE5E-F71E-4151-BD1A-1F6C138700D4@redhat.com>
Message-ID: <CACYLA9EF0rZM3ZU-B_aE4wgG9AvJ5Pgxri+CBfAOe+Qe2gRAiQ@mail.gmail.com>

Hi George,

Today I went through the Drools documentation. I am afraid that it could be
overkill, but anyway, I posted a question to the Drools ML:

https://groups.google.com/forum/#!topic/drools-usage/VHqb-BZZiBI

Cheers,
Ivan

On Fri, Nov 28, 2014 at 2:48 PM, George Gastaldi <ggastald at redhat.com>
wrote:

> Sounds good
>
>
>
> Em 28/11/2014, ?s 10:38, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
> escreveu:
>
> I don't have any experience with Drools or rules engines per se. I may try
> to hack something and based on that we can think whether it is worth the
> effort. OK?
>
> On Fri, Nov 28, 2014 at 2:34 PM, George Gastaldi <ggastald at redhat.com>
> wrote:
>
>> Yes, I agree.
>>
>> However I wonder if these combinations wouldn't become too hard to
>> maintain? This looks like something that could be implemented using a rule
>> engine, like Drools.
>>
>> Thoughts?
>>
>>
>> Em 28/11/2014, ?s 07:37, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>> escreveu:
>>
>> Hi George,
>>
>> This sounds a bit complex :)
>>
>> In summary we have the following three situations:
>>
>> 1) Application server type of container + primary JPA provider, e.g.
>> Wildfly + Hibernate JPA
>> 2) Application server type of container + other JPA provider, e.g.Wildfly
>> + Eclipselink
>> 3) Non application server type of container, i.e. application has to come
>> packaged with the JPA libraries, e.g. Tomcat
>>
>> At the moment Forge supports 1). Adding support for 3) would not be very
>> hard I think. However we should handle 2) case by case I guess. I think
>> that we definitely need an abstraction in the JPA commands that knows how
>> to deal with the container+provider combinations.
>>
>> WDYT?
>>
>> Cheers,
>> Ivan
>>
>> On Fri, Nov 28, 2014 at 1:57 AM, George Gastaldi <ggastald at redhat.com>
>> wrote:
>>
>>> I think this involves doing what's defined in
>>> https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide
>>> We should be able to do the necessary changes in the project, however I
>>> think we may need to point users to this documentation to handle the
>>> changes in the AS itself (or ask Forge to do that itself)
>>>
>>>
>>>
>>> Em 27/11/2014, ?s 19:58, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>>> escreveu:
>>>
>>> Thanks George!
>>>
>>> So I have attached the test. You can put it in the javaee addon, under
>>> the test folder. It's located in
>>> the org.jboss.forge.addon.javaee.jpa.ui.setup package. After you run it,
>>> look for the 'dependencies = ' string in the output. I've set it up to use
>>> EclipseLink on Wildfly container. I suppose it is not going to work with
>>> the JPA API dependency only, is it?
>>>
>>> Cheers,
>>> Ivan
>>>
>>> On Thu, Nov 27, 2014 at 11:35 PM, George Gastaldi <ggastald at redhat.com>
>>> wrote:
>>>
>>>> Try doing project.getFacet(MavenFacet.class).getModel() and you should
>>>> have the pom.xml model available
>>>>
>>>>
>>>>
>>>> Em 27/11/2014, ?s 19:28, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>>>> escreveu:
>>>>
>>>> So I was preparing the test. I wanted to create a test case that prints
>>>> the content of the pom.xml after it invokes the setup command. Here is how
>>>> I prepare everything:
>>>>
>>>> @Inject
>>>> private UITestHarness testHarness;
>>>>
>>>> @Inject
>>>> private ProjectFactory projectFactory;
>>>>
>>>> @Inject
>>>> private EclipseLinkProvider provider;
>>>>
>>>> @Inject
>>>> private WildflyContainer wildflyContainer;
>>>>
>>>> @Test
>>>> public void testPomXmlContent() throws Exception
>>>> {
>>>>    Project project = projectFactory.createTempProject();
>>>>    WizardCommandController tester = testHarness.createWizardController(JPASetupWizard.class,
>>>>             project.getRoot());
>>>>
>>>>    tester.initialize();
>>>>
>>>>    // Setting UI values
>>>>    tester.setValueFor("jpaVersion", "2.1");
>>>>    tester.setValueFor("provider", provider);
>>>>    tester.setValueFor("container", wildflyContainer);
>>>>
>>>>    tester.next().initialize();
>>>>
>>>>    Assert.assertTrue(tester.isValid());
>>>>    tester.execute();
>>>> }
>>>>
>>>> And now I want to somehow get the dependency facet or some other facet
>>>> and print the content of pom.xml (or the dependencies). How can I do that?
>>>>
>>>> Thanks,
>>>> Ivan
>>>>
>>>> On Wed, Nov 26, 2014 at 10:56 AM, Ivan St. Ivanov <
>>>> ivan.st.ivanov at gmail.com> wrote:
>>>>
>>>>> Hi George,
>>>>>
>>>>> I can work on providing those tests and crafting a solution for the
>>>>> case when the JPA provider is not packed with the target container. Will
>>>>> jump in the IRC channel this week and discuss in more details with you.
>>>>>
>>>>> I see that the JavaEEDefaultContainer implements methods that imply
>>>>> JTA data source. No matter that SAP HCP is built on top of Tomcat, we have
>>>>> our own persistence service, which provides JTA data source. So, generally
>>>>> you are right that I should not extend that abstract class, but in this
>>>>> concrete case with HANA Cloud Platform it is the right thing to do.
>>>>>
>>>>> Cheers,
>>>>> Ivan
>>>>>
>>>>> On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>  Right, I think this makes sense. We might need to add more tests
>>>>>> under these conditions. This area sure needs a bit of improvement.
>>>>>>
>>>>>>  It looks like SAPHanaCloudPlatformContainer shouldn't be extending
>>>>>> JavaEEDefaultContainer, afaik that is only meant to be extended by
>>>>>> implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic,
>>>>>> GlassFish).
>>>>>>
>>>>>>  On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
>>>>>>
>>>>>> Hi George,
>>>>>>
>>>>>>  I was thinking of something general in the area of tying up
>>>>>> somehow (not coupling) the JPA containers and providers. The containers
>>>>>> know very well whether they have JPA support at all or, if they have, what
>>>>>> is their native provider (e.g. Hibernate for Wildfly). So IMHO whenever the
>>>>>> user specifies a container with a provider the setup command should do the
>>>>>> following:
>>>>>>
>>>>>>  1) Validate whether this combination is possible at all (e.g. not
>>>>>> sure what will happen if we specify Wildfly with EclipseLink, at the moment
>>>>>> it fails)
>>>>>> 2) If the current container does not have built-in support for JPA
>>>>>> (i.e. it is based on Tomcat, like SAP HCP) or it supports natively
>>>>>> different JPA provider, then add the listDependencies() content to the
>>>>>> pom.xml in the appropriate scope
>>>>>>
>>>>>>  Something like this. Not sure though how was this whole thing
>>>>>> intended to work: do we need to fully decouple providers and containers in
>>>>>> the JPA addon?
>>>>>>
>>>>>>  Cheers,
>>>>>> Ivan
>>>>>>
>>>>>> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi Ivan,
>>>>>>>
>>>>>>> Yes, that's the idea. It's strange that this method is not being
>>>>>>> called. I'll investigate further.
>>>>>>>
>>>>>>> Another solution would be to create a new Forge's
>>>>>>> PersistenceProvider implementation in a separate addon and select that
>>>>>>> instead when running Jpa:Setup.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> George Gastaldi
>>>>>>>
>>>>>>>
>>>>>>> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com>
>>>>>>> escreveu:
>>>>>>>  >
>>>>>>> > Hi everybody,
>>>>>>> >
>>>>>>> > I have the following usecase. I am developing a web application
>>>>>>> that uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud
>>>>>>> Platform (think of it as Tomcat). Which means that I need the Eclipse Link
>>>>>>> dependencies in the pom.xml in the compile scope. When I generated the
>>>>>>> project and set up Eclipse Link, I got this in the pom:
>>>>>>> >
>>>>>>> >   <dependencies>
>>>>>>> >     <dependency>
>>>>>>> >       <groupId>org.hibernate.javax.persistence</groupId>
>>>>>>> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
>>>>>>> >       <scope>provided</scope>
>>>>>>> >     </dependency>
>>>>>>> >   </dependencies>
>>>>>>> >
>>>>>>> > However, I rather need something like:
>>>>>>> >
>>>>>>> >         <dependency>
>>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>>> >             <artifactId>javax.persistence</artifactId>
>>>>>>> >         </dependency>
>>>>>>> >         <dependency>
>>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>>> >             <artifactId>eclipselink</artifactId>
>>>>>>> >         </dependency>
>>>>>>> >
>>>>>>> > I see in
>>>>>>> org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>>>>>>> >
>>>>>>> >
>>>>>>> >    @Override
>>>>>>> >    public List<Dependency> listDependencies()
>>>>>>> >    {
>>>>>>> >       return Arrays.asList((Dependency)
>>>>>>> DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>>>>>>> >                (Dependency)
>>>>>>> DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>>>>>>> >    }
>>>>>>> >
>>>>>>> > So we already have functionality on provider level that knows
>>>>>>> which are the dependencies. However, it seems that this method is not
>>>>>>> called. What was the idea of having it? How can I make sure that the
>>>>>>> dependencies are correctly configured?
>>>>>>> >
>>>>>>> > I think that it has something to do with the type of the
>>>>>>> container: if it is SAP HANA Cloud Platform, then find the dependencies for
>>>>>>> the JPA provider and add them in the default scope of the pom.xml instead
>>>>>>> of adding hibernate-jpa-2.0-api. If it is a full fledged application
>>>>>>> server, then we can go with the API in provided scope. Something like this.
>>>>>>> >
>>>>>>> > WDYT?
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> > Ivan
>>>>>>>  > _______________________________________________
>>>>>>> > forge-dev mailing list
>>>>>>> > forge-dev at lists.jboss.org
>>>>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> forge-dev mailing list
>>>>>>> forge-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> forge-dev mailing listforge-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> forge-dev mailing list
>>>>>> forge-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>
>>>
>>> <JPASetupDifferentProviderTest.java>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141130/9cd54cb9/attachment-0001.html 

From ggastald at redhat.com  Sun Nov 30 16:12:00 2014
From: ggastald at redhat.com (George Gastaldi)
Date: Sun, 30 Nov 2014 16:12:00 -0500 (EST)
Subject: [forge-dev] JPA setup command question
In-Reply-To: <CACYLA9EF0rZM3ZU-B_aE4wgG9AvJ5Pgxri+CBfAOe+Qe2gRAiQ@mail.gmail.com>
References: <CACYLA9Gjsy-bCn1ig5U-Ly3T79vGNPJ9yqfhJoCkw9rb+jnFYQ@mail.gmail.com>
	<23F583A7-9F30-49D0-B497-944E5AE77101@redhat.com>
	<CACYLA9EsxV7WtckAwNKz1v8e5V+aSdOAsrMPWDbQSexGv=_iMw@mail.gmail.com>
	<5473321F.5090302@redhat.com>
	<CACYLA9HA-3=huT4HzLQ+ycnkuPWVkCx-vY95Gb6ZTJdiEG1azA@mail.gmail.com>
	<CACYLA9G=VnQv8CzcGdYaLLe4d-NtBCMNONWBjbbW23M-MZ9pFQ@mail.gmail.com>
	<0B093E63-9DD8-46E2-B060-CC713BEA0DC3@redhat.com>
	<CACYLA9FwKhx4oRjkb6ciVNXjfWwUG18cOVYx48VWRL6bFCfKtg@mail.gmail.com>
	<F86B0179-CE39-438B-85B4-130019F60B29@redhat.com>
	<CACYLA9E8HW+eoRsEQHU-deORFC0b4MsoJncUnLR7UC_sHia79Q@mail.gmail.com>
	<9B818D2C-C569-4D3F-BF92-6F6BABABF81F@redhat.com>
	<CACYLA9G6mM_smOeSwdza+2Hdt2Am9v5K5ftrV0Ky0HDmck6L+Q@mail.gmail.com>
	<EC64AE5E-F71E-4151-BD1A-1F6C138700D4@redhat.com>
	<CACYLA9EF0rZM3ZU-B_aE4wgG9AvJ5Pgxri+CBfAOe+Qe2gRAiQ@mail.gmail.com>
Message-ID: <CF88F5EB-0B90-4E41-A406-0FD2A5682B06@redhat.com>

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 at 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 at redhat.com> wrote:
>> Sounds good
>> 
>> 
>> 
>>> Em 28/11/2014, ?s 10:38, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>> 
>> 
>>> I don't have any experience with Drools or rules engines per se. I may try to hack something and based on that we can think whether it is worth the effort. OK?
>>> 
>>>> On Fri, Nov 28, 2014 at 2:34 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>> Yes, I agree. 
>>>> 
>>>> However I wonder if these combinations wouldn't become too hard to maintain? This looks like something that could be implemented using a rule engine, like Drools. 
>>>> 
>>>> Thoughts? 
>>>> 
>>>> 
>>>>> Em 28/11/2014, ?s 07:37, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>>>> 
>>>> 
>>>>> Hi George,
>>>>> 
>>>>> This sounds a bit complex :)
>>>>> 
>>>>> In summary we have the following three situations:
>>>>> 
>>>>> 1) Application server type of container + primary JPA provider, e.g. Wildfly + Hibernate JPA
>>>>> 2) Application server type of container + other JPA provider, e.g.Wildfly + Eclipselink
>>>>> 3) Non application server type of container, i.e. application has to come packaged with the JPA libraries, e.g. Tomcat
>>>>> 
>>>>> At the moment Forge supports 1). Adding support for 3) would not be very hard I think. However we should handle 2) case by case I guess. I think that we definitely need an abstraction in the JPA commands that knows how to deal with the container+provider combinations.
>>>>> 
>>>>> WDYT?
>>>>> 
>>>>> Cheers,
>>>>> Ivan
>>>>> 
>>>>>> On Fri, Nov 28, 2014 at 1:57 AM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>> I think this involves doing what's defined in https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide 
>>>>>> We should be able to do the necessary changes in the project, however I think we may need to point users to this documentation to handle the changes in the AS itself (or ask Forge to do that itself)
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Em 27/11/2014, ?s 19:58, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>>>>>> 
>>>>>> 
>>>>>>> Thanks George!
>>>>>>> 
>>>>>>> So I have attached the test. You can put it in the javaee addon, under the test folder. It's located in the org.jboss.forge.addon.javaee.jpa.ui.setup package. After you run it, look for the 'dependencies = ' string in the output. I've set it up to use EclipseLink on Wildfly container. I suppose it is not going to work with the JPA API dependency only, is it?
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Ivan
>>>>>>> 
>>>>>>>> On Thu, Nov 27, 2014 at 11:35 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>>>> Try doing project.getFacet(MavenFacet.class).getModel() and you should have the pom.xml model available
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Em 27/11/2014, ?s 19:28, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>>>>>>>> 
>>>>>>>> 
>>>>>>>>> So I was preparing the test. I wanted to create a test case that prints the content of the pom.xml after it invokes the setup command. Here is how I prepare everything:
>>>>>>>>> 
>>>>>>>>> @Inject
>>>>>>>>> private UITestHarness testHarness;
>>>>>>>>> 
>>>>>>>>> @Inject
>>>>>>>>> private ProjectFactory projectFactory;
>>>>>>>>> 
>>>>>>>>> @Inject
>>>>>>>>> private EclipseLinkProvider provider;
>>>>>>>>> 
>>>>>>>>> @Inject
>>>>>>>>> private WildflyContainer wildflyContainer;
>>>>>>>>> @Test
>>>>>>>>> public void testPomXmlContent() throws Exception
>>>>>>>>> {
>>>>>>>>>    Project project = projectFactory.createTempProject();
>>>>>>>>>    WizardCommandController tester = testHarness.createWizardController(JPASetupWizard.class,
>>>>>>>>>             project.getRoot());
>>>>>>>>> 
>>>>>>>>>    tester.initialize();
>>>>>>>>> 
>>>>>>>>>    // Setting UI values
>>>>>>>>>    tester.setValueFor("jpaVersion", "2.1");
>>>>>>>>>    tester.setValueFor("provider", provider);
>>>>>>>>>    tester.setValueFor("container", wildflyContainer);
>>>>>>>>> 
>>>>>>>>>    tester.next().initialize();
>>>>>>>>> 
>>>>>>>>>    Assert.assertTrue(tester.isValid());
>>>>>>>>>    tester.execute();
>>>>>>>>> }
>>>>>>>>> And now I want to somehow get the dependency facet or some other facet and print the content of pom.xml (or the dependencies). How can I do that?
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Ivan
>>>>>>>>> 
>>>>>>>>>> On Wed, Nov 26, 2014 at 10:56 AM, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> wrote:
>>>>>>>>>> Hi George,
>>>>>>>>>> 
>>>>>>>>>> I can work on providing those tests and crafting a solution for the case when the JPA provider is not packed with the target container. Will jump in the IRC channel this week and discuss in more details with you.
>>>>>>>>>> 
>>>>>>>>>> I see that the JavaEEDefaultContainer implements methods that imply JTA data source. No matter that SAP HCP is built on top of Tomcat, we have our own persistence service, which provides JTA data source. So, generally you are right that I should not extend that abstract class, but in this concrete case with HANA Cloud Platform it is the right thing to do.
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> Ivan
>>>>>>>>>> 
>>>>>>>>>>> On Mon, Nov 24, 2014 at 3:26 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>>>>>>> Right, I think this makes sense. We might need to add more tests under these conditions. This area sure needs a bit of improvement.
>>>>>>>>>>> 
>>>>>>>>>>> It looks like SAPHanaCloudPlatformContainer shouldn't be extending JavaEEDefaultContainer, afaik that is only meant to be extended by implementations of JavaEE servers (TomEE, Wildfly, EAP, Weblogic, GlassFish).
>>>>>>>>>>> 
>>>>>>>>>>>> On 11/24/2014 10:39 AM, Ivan St. Ivanov wrote:
>>>>>>>>>>>> Hi George,
>>>>>>>>>>>> 
>>>>>>>>>>>> I was thinking of something general in the area of tying up somehow (not coupling) the JPA containers and providers. The containers know very well whether they have JPA support at all or, if they have, what is their native provider (e.g. Hibernate for Wildfly). So IMHO whenever the user specifies a container with a provider the setup command should do the following:
>>>>>>>>>>>> 
>>>>>>>>>>>> 1) Validate whether this combination is possible at all (e.g. not sure what will happen if we specify Wildfly with EclipseLink, at the moment it fails)
>>>>>>>>>>>> 2) If the current container does not have built-in support for JPA (i.e. it is based on Tomcat, like SAP HCP) or it supports natively different JPA provider, then add the listDependencies() content to the pom.xml in the appropriate scope
>>>>>>>>>>>> 
>>>>>>>>>>>> Something like this. Not sure though how was this whole thing intended to work: do we need to fully decouple providers and containers in the JPA addon?
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Ivan
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Mon, Nov 24, 2014 at 1:11 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>>>>>>>>> Hi Ivan,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Yes, that's the idea. It's strange that this method is not being called. I'll investigate further.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Another solution would be to create a new Forge's PersistenceProvider implementation in a separate addon and select that instead when running Jpa:Setup.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> George Gastaldi
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> > Em 24/11/2014, ?s 08:25, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> escreveu:
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > Hi everybody,
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > I have the following usecase. I am developing a web application that uses JPA with Eclipse Link and will be deployed on SAP HANA Cloud Platform (think of it as Tomcat). Which means that I need the Eclipse Link dependencies in the pom.xml in the compile scope. When I generated the project and set up Eclipse Link, I got this in the pom:
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >   <dependencies>
>>>>>>>>>>>>> >     <dependency>
>>>>>>>>>>>>> >       <groupId>org.hibernate.javax.persistence</groupId>
>>>>>>>>>>>>> >       <artifactId>hibernate-jpa-2.0-api</artifactId>
>>>>>>>>>>>>> >       <scope>provided</scope>
>>>>>>>>>>>>> >     </dependency>
>>>>>>>>>>>>> >   </dependencies>
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > However, I rather need something like:
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >         <dependency>
>>>>>>>>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>>>>>>>>> >             <artifactId>javax.persistence</artifactId>
>>>>>>>>>>>>> >         </dependency>
>>>>>>>>>>>>> >         <dependency>
>>>>>>>>>>>>> >             <groupId>org.eclipse.persistence</groupId>
>>>>>>>>>>>>> >             <artifactId>eclipselink</artifactId>
>>>>>>>>>>>>> >         </dependency>
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > I see in org.jboss.forge.addon.javaee.jpa.providers.EclipseLinkProvider:
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >    @Override
>>>>>>>>>>>>> >    public List<Dependency> listDependencies()
>>>>>>>>>>>>> >    {
>>>>>>>>>>>>> >       return Arrays.asList((Dependency) DependencyBuilder.create("org.eclipse.persistence:eclipselink"),
>>>>>>>>>>>>> >                (Dependency) DependencyBuilder.create("org.eclipse.persistence:javax.persistence"));
>>>>>>>>>>>>> >    }
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > So we already have functionality on provider level that knows which are the dependencies. However, it seems that this method is not called. What was the idea of having it? How can I make sure that the dependencies are correctly configured?
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > I think that it has something to do with the type of the container: if it is SAP HANA Cloud Platform, then find the dependencies for the JPA provider and add them in the default scope of the pom.xml instead of adding                 hibernate-jpa-2.0-api. If it is a full fledged application server, then we can go with the API in provided scope. Something like this.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > WDYT?
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > Thanks,
>>>>>>>>>>>>> > Ivan
>>>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>>>> > forge-dev mailing list
>>>>>>>>>>>>> > forge-dev at lists.jboss.org
>>>>>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>>>>>>> 
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> forge-dev mailing list
>>>>>>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> forge-dev mailing list
>>>>>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> forge-dev mailing list
>>>>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> forge-dev mailing list
>>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> forge-dev mailing list
>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>> 
>>>>>>> <JPASetupDifferentProviderTest.java>
>>>>>>> _______________________________________________
>>>>>>> forge-dev mailing list
>>>>>>> forge-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>> 
>>>>>> _______________________________________________
>>>>>> forge-dev mailing list
>>>>>> forge-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>> 
>>>>> _______________________________________________
>>>>> forge-dev mailing list
>>>>> forge-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>> 
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> 
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>> 
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
> 
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141130/8d7679f3/attachment-0001.html