3:52 p.m.
Hi folks,
As some of you probably heard, in Bulgarian JUG we are going to adopt an
addon (as George put it a couple of months ago). Beginning of August we are
going to develop a Forge extension for Spring Boot. One of the things that
we are not sure yet how to tackle is persistence.
You see, Spring supports JPA. However instead of configuring it in the Java
EE way with persistence.xml, in Spring Boot they use a properties file for
that (and for all their configuration). The current JPA facet
implementations however are developed with presistence.xml in mind. The JPA
setup wizard itself is also bound somehow to presistence.xml - it picks the
facet to install based on that file.
What we want to do is not to rewrite all the Forge commands for JPA just
because of the fact above. We were thinking of a small change - extend
JPAFacet with SpringBootJPAFacet. And then add a new implementation of
PersistenceContainer -> SpringBootContainer or something? And then we have
to change JPASetupWizardImpl to pick the facet not only based on the JPA
version, but also based on the container.
Or maybe there is a better way?
I am expecting your feedback :)
Cheers,
Ivan
2:27 p.m.
Hi Ivan,
JPAFacet depends on having a PersistenceCommonDescriptor
(https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jb...),
so I guess that extending JPAFacet is not a good idea in this case. Is
it a problem if the persistence.xml is created for a Spring Boot project?
Otherwise, I'd suggest you to create the SpringBootJPAFacet without
reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as they
really don't follow JavaEE in this context beyond the JPA JARs.
Best Regards,
George Gastaldi
On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote:
Hi folks,
As some of you probably heard, in Bulgarian JUG we are going to adopt
an addon (as George put it a couple of months ago). Beginning of
August we are going to develop a Forge extension for Spring Boot. One
of the things that we are not sure yet how to tackle is persistence.
You see, Spring supports JPA. However instead of configuring it in the
Java EE way with persistence.xml, in Spring Boot they use a properties
file for that (and for all their configuration). The current JPA facet
implementations however are developed with presistence.xml in mind.
The JPA setup wizard itself is also bound somehow to presistence.xml -
it picks the facet to install based on that file.
What we want to do is not to rewrite all the Forge commands for JPA
just because of the fact above. We were thinking of a small change -
extend JPAFacet with SpringBootJPAFacet. And then add a new
implementation of PersistenceContainer -> SpringBootContainer or
something? And then we have to change JPASetupWizardImpl to pick the
facet not only based on the JPA version, but also based on the container.
Or maybe there is a better way?
I am expecting your feedback :)
Cheers,
Ivan
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
12:22 p.m.
Hi George,
Thanks for your answer! I add our Spring Boot expert Nayden to the loop.
Well, according to the Spring documentation it is possible to have
persistence.xml:
http://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-...
However, I see it more as a hack from our side.
Cheers,
Ivan
On Mon, Jul 27, 2015 at 10:27 PM, George Gastaldi <ggastald(a)redhat.com>
wrote:
Hi Ivan,
JPAFacet depends on having a PersistenceCommonDescriptor (
https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jb...),
so I guess that extending JPAFacet is not a good idea in this case. Is it a
problem if the persistence.xml is created for a Spring Boot project?
Otherwise, I'd suggest you to create the SpringBootJPAFacet without
reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as they
really don't follow JavaEE in this context beyond the JPA JARs.
Best Regards,
George Gastaldi
On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote:
Hi folks,
As some of you probably heard, in Bulgarian JUG we are going to adopt an
addon (as George put it a couple of months ago). Beginning of August we are
going to develop a Forge extension for Spring Boot. One of the things that
we are not sure yet how to tackle is persistence.
You see, Spring supports JPA. However instead of configuring it in the
Java EE way with persistence.xml, in Spring Boot they use a properties file
for that (and for all their configuration). The current JPA facet
implementations however are developed with presistence.xml in mind. The JPA
setup wizard itself is also bound somehow to presistence.xml - it picks the
facet to install based on that file.
What we want to do is not to rewrite all the Forge commands for JPA just
because of the fact above. We were thinking of a small change - extend
JPAFacet with SpringBootJPAFacet. And then add a new implementation of
PersistenceContainer -> SpringBootContainer or something? And then we have
to change JPASetupWizardImpl to pick the facet not only based on the JPA
version, but also based on the container.
Or maybe there is a better way?
I am expecting your feedback :)
Cheers,
Ivan
_______________________________________________
forge-dev mailing
listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
3:15 p.m.
Yes it is a hack (to keep the persistance.xml and is not good :(
So we indeed have to create some SpringBootJPAFacet to bypass the
generation of persistance.xml and to just add few extra properties to the
application.properties file ( basically 5-6 lines ).
The idea with spring boot is 0 configuration and everything is
automatically configured ( the only configuration you do is in one central
properties file)
Nayden
On Wed, Jul 29, 2015 at 8:22 PM, Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>
wrote:
Hi George,
Thanks for your answer! I add our Spring Boot expert Nayden to the loop.
Well, according to the Spring documentation it is possible to have
persistence.xml:
http://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-...
However, I see it more as a hack from our side.
Cheers,
Ivan
On Mon, Jul 27, 2015 at 10:27 PM, George Gastaldi <ggastald(a)redhat.com>
wrote:
> Hi Ivan,
>
> JPAFacet depends on having a PersistenceCommonDescriptor (
>
https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jb...),
> so I guess that extending JPAFacet is not a good idea in this case. Is it a
> problem if the persistence.xml is created for a Spring Boot project?
>
> Otherwise, I'd suggest you to create the SpringBootJPAFacet without
> reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as they
> really don't follow JavaEE in this context beyond the JPA JARs.
>
> Best Regards,
>
> George Gastaldi
>
>
> On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote:
>
> Hi folks,
>
> As some of you probably heard, in Bulgarian JUG we are going to adopt
> an addon (as George put it a couple of months ago). Beginning of August we
> are going to develop a Forge extension for Spring Boot. One of the things
> that we are not sure yet how to tackle is persistence.
>
> You see, Spring supports JPA. However instead of configuring it in the
> Java EE way with persistence.xml, in Spring Boot they use a properties file
> for that (and for all their configuration). The current JPA facet
> implementations however are developed with presistence.xml in mind. The JPA
> setup wizard itself is also bound somehow to presistence.xml - it picks the
> facet to install based on that file.
>
> What we want to do is not to rewrite all the Forge commands for JPA
> just because of the fact above. We were thinking of a small change - extend
> JPAFacet with SpringBootJPAFacet. And then add a new implementation of
> PersistenceContainer -> SpringBootContainer or something? And then we have
> to change JPASetupWizardImpl to pick the facet not only based on the JPA
> version, but also based on the container.
>
> Or maybe there is a better way?
>
> I am expecting your feedback :)
>
> Cheers,
> Ivan
>
>
> _______________________________________________
> forge-dev mailing
listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
3:31 p.m.
How about a SpringBootFacet with a ge/setProperties() method to handle these central
properties?
As for the JPAFacet, it is necessary to have it installed for the JPA: New Entity to
function properly, for example, so I guess you might need to extend it and override the
method that creates the persistence.xml file. <div>
</div><div>
</div><div>-------- Mensagem original --------</div><div>De:
Nayden Gochev <gochev(a)gmail.com> </div><div>Data: 29/07/2015 17:21
(GMT-03:00) </div><div>Para: "Ivan St. Ivanov"
<ivan.st.ivanov(a)gmail.com> </div><div>Cc: forge-dev List
<forge-dev(a)lists.jboss.org> </div><div>Assunto: Re: [forge-dev] Approach
to Spring Boot handling JPA </div><div>
</div>Yes it is a hack (to keep the persistance.xml and is not good :(
So we indeed have to create some SpringBootJPAFacet to bypass the
generation of persistance.xml and to just add few extra properties to the
application.properties file ( basically 5-6 lines ).
The idea with spring boot is 0 configuration and everything is
automatically configured ( the only configuration you do is in one central
properties file)
Nayden
On Wed, Jul 29, 2015 at 8:22 PM, Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>
wrote:
Hi George,
Thanks for your answer! I add our Spring Boot expert Nayden to the loop.
Well, according to the Spring documentation it is possible to have
persistence.xml:
http://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-...
However, I see it more as a hack from our side.
Cheers,
Ivan
On Mon, Jul 27, 2015 at 10:27 PM, George Gastaldi <ggastald(a)redhat.com>
wrote:
> Hi Ivan,
>
> JPAFacet depends on having a PersistenceCommonDescriptor (
>
https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jb...),
> so I guess that extending JPAFacet is not a good idea in this case. Is it a
> problem if the persistence.xml is created for a Spring Boot project?
>
> Otherwise, I'd suggest you to create the SpringBootJPAFacet without
> reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as they
> really don't follow JavaEE in this context beyond the JPA JARs.
>
> Best Regards,
>
> George Gastaldi
>
>
> On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote:
>
> Hi folks,
>
> As some of you probably heard, in Bulgarian JUG we are going to adopt
> an addon (as George put it a couple of months ago). Beginning of August we
> are going to develop a Forge extension for Spring Boot. One of the things
> that we are not sure yet how to tackle is persistence.
>
> You see, Spring supports JPA. However instead of configuring it in the
> Java EE way with persistence.xml, in Spring Boot they use a properties file
> for that (and for all their configuration). The current JPA facet
> implementations however are developed with presistence.xml in mind. The JPA
> setup wizard itself is also bound somehow to presistence.xml - it picks the
> facet to install based on that file.
>
> What we want to do is not to rewrite all the Forge commands for JPA
> just because of the fact above. We were thinking of a small change - extend
> JPAFacet with SpringBootJPAFacet. And then add a new implementation of
> PersistenceContainer -> SpringBootContainer or something? And then we have
> to change JPASetupWizardImpl to pick the facet not only based on the JPA
> version, but also based on the container.
>
> Or maybe there is a better way?
>
> I am expecting your feedback :)
>
> Cheers,
> Ivan
>
>
> _______________________________________________
> forge-dev mailing
listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
2:22 a.m.
Hi George,
Then maybe we should re-evaluate the initial proposal:
What we want to do is not to rewrite all the Forge commands for JPA just
because of the fact above. We were thinking of a small change - extend
JPAFacet with SpringBootJPAFacet. And then add a new implementation of
PersistenceContainer -> SpringBootContainer or something? And then we have
to change JPASetupWizardImpl to pick the facet not only based on the JPA
version, but also based on the container.
Thanks,
Ivan
On Wed, Jul 29, 2015 at 11:31 PM, George Gastaldi <ggastald(a)redhat.com>
wrote:
How about a SpringBootFacet with a ge/setProperties() method to
handle
these central properties?
As for the JPAFacet, it is necessary to have it installed for the JPA: New
Entity to function properly, for example, so I guess you might need to
extend it and override the method that creates the persistence.xml file.
-------- Mensagem original --------
De: Nayden Gochev <gochev(a)gmail.com>
Data: 29/07/2015 17:21 (GMT-03:00)
Para: "Ivan St. Ivanov" <ivan.st.ivanov(a)gmail.com>
Cc: forge-dev List <forge-dev(a)lists.jboss.org>
Assunto: Re: [forge-dev] Approach to Spring Boot handling JPA
Yes it is a hack (to keep the persistance.xml and is not good :(
So we indeed have to create some SpringBootJPAFacet to bypass the
generation of persistance.xml and to just add few extra properties to the
application.properties file ( basically 5-6 lines ).
The idea with spring boot is 0 configuration and everything is
automatically configured ( the only configuration you do is in one central
properties file)
Nayden
On Wed, Jul 29, 2015 at 8:22 PM, Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com
> wrote:
> Hi George,
>
> Thanks for your answer! I add our Spring Boot expert Nayden to the loop.
>
> Well, according to the Spring documentation it is possible to have
> persistence.xml:
>
http://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-...
>
> However, I see it more as a hack from our side.
>
> Cheers,
> Ivan
>
> On Mon, Jul 27, 2015 at 10:27 PM, George Gastaldi <ggastald(a)redhat.com>
> wrote:
>
>> Hi Ivan,
>>
>> JPAFacet depends on having a PersistenceCommonDescriptor (
>>
https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jb...),
>> so I guess that extending JPAFacet is not a good idea in this case. Is it a
>> problem if the persistence.xml is created for a Spring Boot project?
>>
>> Otherwise, I'd suggest you to create the SpringBootJPAFacet without
>> reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as
they
>> really don't follow JavaEE in this context beyond the JPA JARs.
>>
>> Best Regards,
>>
>> George Gastaldi
>>
>>
>> On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote:
>>
>> Hi folks,
>>
>> As some of you probably heard, in Bulgarian JUG we are going to adopt an
>> addon (as George put it a couple of months ago). Beginning of August we are
>> going to develop a Forge extension for Spring Boot. One of the things that
>> we are not sure yet how to tackle is persistence.
>>
>> You see, Spring supports JPA. However instead of configuring it in the
>> Java EE way with persistence.xml, in Spring Boot they use a properties file
>> for that (and for all their configuration). The current JPA facet
>> implementations however are developed with presistence.xml in mind. The JPA
>> setup wizard itself is also bound somehow to presistence.xml - it picks the
>> facet to install based on that file.
>>
>> What we want to do is not to rewrite all the Forge commands for JPA just
>> because of the fact above. We were thinking of a small change - extend
>> JPAFacet with SpringBootJPAFacet. And then add a new implementation of
>> PersistenceContainer -> SpringBootContainer or something? And then we have
>> to change JPASetupWizardImpl to pick the facet not only based on the JPA
>> version, but also based on the container.
>>
>> Or maybe there is a better way?
>>
>> I am expecting your feedback :)
>>
>> Cheers,
>> Ivan
>>
>>
>> _______________________________________________
>> forge-dev mailing
listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
>
6:56 a.m.
Hey George,
I proceeded as we discussed on the meeting on Tuesday. However, I had to
copy some of the code of the AbstractJPAFacetImpl in the
SpringBootJPAFacet: the contents of the methods getEntityPackage,
getEntityPackageDir and getAllEntities.
Can we somehow move these (and probably other) methods to the API project,
so that they can be reused?
Thanks,
Ivan
On Thu, Jul 30, 2015 at 10:22 AM, Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>
wrote:
Hi George,
Then maybe we should re-evaluate the initial proposal:
What we want to do is not to rewrite all the Forge commands for JPA just
because of the fact above. We were thinking of a small change - extend
JPAFacet with SpringBootJPAFacet. And then add a new implementation of
PersistenceContainer -> SpringBootContainer or something? And then we have
to change JPASetupWizardImpl to pick the facet not only based on the JPA
version, but also based on the container.
Thanks,
Ivan
On Wed, Jul 29, 2015 at 11:31 PM, George Gastaldi <ggastald(a)redhat.com>
wrote:
> How about a SpringBootFacet with a ge/setProperties() method to handle
> these central properties?
>
> As for the JPAFacet, it is necessary to have it installed for the JPA:
> New Entity to function properly, for example, so I guess you might need to
> extend it and override the method that creates the persistence.xml file.
>
>
> -------- Mensagem original --------
> De: Nayden Gochev <gochev(a)gmail.com>
> Data: 29/07/2015 17:21 (GMT-03:00)
> Para: "Ivan St. Ivanov" <ivan.st.ivanov(a)gmail.com>
> Cc: forge-dev List <forge-dev(a)lists.jboss.org>
> Assunto: Re: [forge-dev] Approach to Spring Boot handling JPA
>
>
> Yes it is a hack (to keep the persistance.xml and is not good :(
>
> So we indeed have to create some SpringBootJPAFacet to bypass the
> generation of persistance.xml and to just add few extra properties to the
> application.properties file ( basically 5-6 lines ).
>
> The idea with spring boot is 0 configuration and everything is
> automatically configured ( the only configuration you do is in one central
> properties file)
>
> Nayden
>
> On Wed, Jul 29, 2015 at 8:22 PM, Ivan St. Ivanov <
> ivan.st.ivanov(a)gmail.com> wrote:
>
>> Hi George,
>>
>> Thanks for your answer! I add our Spring Boot expert Nayden to the loop.
>>
>> Well, according to the Spring documentation it is possible to have
>> persistence.xml:
>>
http://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-...
>>
>> However, I see it more as a hack from our side.
>>
>> Cheers,
>> Ivan
>>
>> On Mon, Jul 27, 2015 at 10:27 PM, George Gastaldi <ggastald(a)redhat.com>
>> wrote:
>>
>>> Hi Ivan,
>>>
>>> JPAFacet depends on having a PersistenceCommonDescriptor (
>>>
https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jb...),
>>> so I guess that extending JPAFacet is not a good idea in this case. Is it a
>>> problem if the persistence.xml is created for a Spring Boot project?
>>>
>>> Otherwise, I'd suggest you to create the SpringBootJPAFacet without
>>> reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as
they
>>> really don't follow JavaEE in this context beyond the JPA JARs.
>>>
>>> Best Regards,
>>>
>>> George Gastaldi
>>>
>>>
>>> On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote:
>>>
>>> Hi folks,
>>>
>>> As some of you probably heard, in Bulgarian JUG we are going to adopt
>>> an addon (as George put it a couple of months ago). Beginning of August we
>>> are going to develop a Forge extension for Spring Boot. One of the things
>>> that we are not sure yet how to tackle is persistence.
>>>
>>> You see, Spring supports JPA. However instead of configuring it in the
>>> Java EE way with persistence.xml, in Spring Boot they use a properties file
>>> for that (and for all their configuration). The current JPA facet
>>> implementations however are developed with presistence.xml in mind. The JPA
>>> setup wizard itself is also bound somehow to presistence.xml - it picks the
>>> facet to install based on that file.
>>>
>>> What we want to do is not to rewrite all the Forge commands for JPA
>>> just because of the fact above. We were thinking of a small change - extend
>>> JPAFacet with SpringBootJPAFacet. And then add a new implementation of
>>> PersistenceContainer -> SpringBootContainer or something? And then we
have
>>> to change JPASetupWizardImpl to pick the facet not only based on the JPA
>>> version, but also based on the container.
>>>
>>> Or maybe there is a better way?
>>>
>>> I am expecting your feedback :)
>>>
>>> Cheers,
>>> Ivan
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing
listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>>
>
9:49 a.m.
Hi Ivan,
Sure, I think we can move the AbstractJPAFacetImpl to API since it's meant to be
extended.
Best Regards,George Gastaldi<div>
</div><div>
</div><div>-------- Mensagem original --------</div><div>De:
"Ivan St. Ivanov" <ivan.st.ivanov(a)gmail.com> </div><div>Data:
07/08/2015 08:56 (GMT-03:00) </div><div>Para: George Gastaldi
<ggastald(a)redhat.com> </div><div>Cc: forge-dev List
<forge-dev(a)lists.jboss.org>, Nayden Gochev <gochev(a)gmail.com>
</div><div>Assunto: Re: [forge-dev] Approach to Spring Boot handling JPA
</div><div>
</div>Hey George,
I proceeded as we discussed on the meeting on Tuesday. However, I had to
copy some of the code of the AbstractJPAFacetImpl in the
SpringBootJPAFacet: the contents of the methods getEntityPackage,
getEntityPackageDir and getAllEntities.
Can we somehow move these (and probably other) methods to the API project,
so that they can be reused?
Thanks,
Ivan
On Thu, Jul 30, 2015 at 10:22 AM, Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>
wrote:
Hi George,
Then maybe we should re-evaluate the initial proposal:
What we want to do is not to rewrite all the Forge commands for JPA just
because of the fact above. We were thinking of a small change - extend
JPAFacet with SpringBootJPAFacet. And then add a new implementation of
PersistenceContainer -> SpringBootContainer or something? And then we have
to change JPASetupWizardImpl to pick the facet not only based on the JPA
version, but also based on the container.
Thanks,
Ivan
On Wed, Jul 29, 2015 at 11:31 PM, George Gastaldi <ggastald(a)redhat.com>
wrote:
> How about a SpringBootFacet with a ge/setProperties() method to handle
> these central properties?
>
> As for the JPAFacet, it is necessary to have it installed for the JPA:
> New Entity to function properly, for example, so I guess you might need to
> extend it and override the method that creates the persistence.xml file.
>
>
> -------- Mensagem original --------
> De: Nayden Gochev <gochev(a)gmail.com>
> Data: 29/07/2015 17:21 (GMT-03:00)
> Para: "Ivan St. Ivanov" <ivan.st.ivanov(a)gmail.com>
> Cc: forge-dev List <forge-dev(a)lists.jboss.org>
> Assunto: Re: [forge-dev] Approach to Spring Boot handling JPA
>
>
> Yes it is a hack (to keep the persistance.xml and is not good :(
>
> So we indeed have to create some SpringBootJPAFacet to bypass the
> generation of persistance.xml and to just add few extra properties to the
> application.properties file ( basically 5-6 lines ).
>
> The idea with spring boot is 0 configuration and everything is
> automatically configured ( the only configuration you do is in one central
> properties file)
>
> Nayden
>
> On Wed, Jul 29, 2015 at 8:22 PM, Ivan St. Ivanov <
> ivan.st.ivanov(a)gmail.com> wrote:
>
>> Hi George,
>>
>> Thanks for your answer! I add our Spring Boot expert Nayden to the loop.
>>
>> Well, according to the Spring documentation it is possible to have
>> persistence.xml:
>>
http://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-...
>>
>> However, I see it more as a hack from our side.
>>
>> Cheers,
>> Ivan
>>
>> On Mon, Jul 27, 2015 at 10:27 PM, George Gastaldi <ggastald(a)redhat.com>
>> wrote:
>>
>>> Hi Ivan,
>>>
>>> JPAFacet depends on having a PersistenceCommonDescriptor (
>>>
https://github.com/forge/core/blob/master/javaee/api/src/main/java/org/jb...),
>>> so I guess that extending JPAFacet is not a good idea in this case. Is it a
>>> problem if the persistence.xml is created for a Spring Boot project?
>>>
>>> Otherwise, I'd suggest you to create the SpringBootJPAFacet without
>>> reusing the JavaEE ones (and create a "Spring Boot: JPA Setup"), as
they
>>> really don't follow JavaEE in this context beyond the JPA JARs.
>>>
>>> Best Regards,
>>>
>>> George Gastaldi
>>>
>>>
>>> On 07/26/2015 05:52 PM, Ivan St. Ivanov wrote:
>>>
>>> Hi folks,
>>>
>>> As some of you probably heard, in Bulgarian JUG we are going to adopt
>>> an addon (as George put it a couple of months ago). Beginning of August we
>>> are going to develop a Forge extension for Spring Boot. One of the things
>>> that we are not sure yet how to tackle is persistence.
>>>
>>> You see, Spring supports JPA. However instead of configuring it in the
>>> Java EE way with persistence.xml, in Spring Boot they use a properties file
>>> for that (and for all their configuration). The current JPA facet
>>> implementations however are developed with presistence.xml in mind. The JPA
>>> setup wizard itself is also bound somehow to presistence.xml - it picks the
>>> facet to install based on that file.
>>>
>>> What we want to do is not to rewrite all the Forge commands for JPA
>>> just because of the fact above. We were thinking of a small change - extend
>>> JPAFacet with SpringBootJPAFacet. And then add a new implementation of
>>> PersistenceContainer -> SpringBootContainer or something? And then we
have
>>> to change JPASetupWizardImpl to pick the facet not only based on the JPA
>>> version, but also based on the container.
>>>
>>> Or maybe there is a better way?
>>>
>>> I am expecting your feedback :)
>>>
>>> Cheers,
>>> Ivan
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing
listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>>
>
3394
days inactive
3406
days old
7 comments
3 participants
participants (3)
-
George Gastaldi -
Ivan St. Ivanov -
Nayden Gochev