You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Eric Charles <er...@apache.org> on 2010/07/11 14:18:12 UTC
Re: JPA for imap 0.1 release
Hi Tim,
So there is consensus to leave the package naming as-is and move
entities with openjpa proprietary extension to the openjpa packages.
Currently, I have no well defined patch (only many trials I made).
I will implement some @ElementJoinColumn and @Index and test it with
real traffic.
Depending on the result and timing, we may integrate the changes in our
upcoming 3.0 M1 release.
I will also need to upgrade the current database schema and datas.
Probably the number of users that need this migration is very limited
(only users running a 3.0 trunk built snapshot).
However, we could use it as a base for the latter migrations and also
for the 2.3 to 3.0 migration.
I will look if an existing JIRA or create a new one to publish the progress.
Tks,
Eric
On 06/26/2010 10:17 AM, Tim-Christian Mundt wrote:
> Hi Norman and Eric,
>
> I fully agree with simply using OpenJPA annotations.
>
> Concerning the openjpa package I think I found what you mean, Eric. It
> was confusing because there are two OpenJPA packages:
> org/apache/james/imap/jpa/mail/model/openjpa
> org/apache/james/imap/jpa/openjpa
>
> The latter is there merely to support the "useStreaming" option, if I
> don't err. The former is also for streaming, so yes, it would make sense
> to rename it. On the other hand we could move all OpenJPA stuff
> to /jpa/openjpa which would basically mean to e.g. put the streaming
> classes into
> org/apache/james/imap/jpa/openjpa/mail/model/streaming
> If everything with proprietary OpenJPA annotations would be in a
> separate package it would become immediate which classes one needs to
> implement in order to create a new provider. That's my vote: stick with
> OpenJPA but still cleanly separate it from standards conforming code.
>
> Eric, could you send us a patch of what you've done so far? Then we can
> finish it (hope you still read this before your trip...)
>
> Tim
>
> Am Freitag, den 25.06.2010, 19:33 +0200 schrieb Norman Maurer:
>
>> Ok so to come to some consequence here.. Let us just use the openjpa
>> annotation stuff.. If we really want to support other JPA
>> implementations we could handle it later..
>>
>> Bye,
>> Norman
>>
>>
>> 2010/6/25 Tim-Christian Mundt<de...@tim-erwin.de>:
>>
>>> Hey,
>>>
>>>
>>>
>>>> I'm also happy with OpenJPA and using its proprietary annotations (not
>>>> classes) doesn't prohibit a developer/deployer to define another JPA
>>>> provider.
>>>>
>>> Right.
>>>
>>>
>>>> What about :
>>>> - @ElementJoinColumn ?
>>>> - @Index ?
>>>>
>>> I'd support those.
>>>
>>>
>>>> - rename 'openjpa' package to 'streaming' ?
>>>>
>>> We already have a streaming package and there is both streaming and
>>> non-streaming for OpenJPA, so why rename the package? Maybe I haven't
>>> fully understood your point.
>>>
>>>
>>>> I will be off for 2 weeks and won't probably be able to continue the
>>>> conversation.
>>>>
>>> Hope I may say "Happy vacations" :)
>>>
>>> Best
>>> Tim
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JPA for imap 0.1 release
Posted by Tim-Christian Mundt <de...@tim-erwin.de>.
Hi Eric,
that sounds good. Let's see, if we can provide a sql-only migration
script. After solving issue IMAP-168 the database schema will change
again, so we'll have to take care of that, too.
Best
Tim
Am Sonntag, den 11.07.2010, 14:18 +0200 schrieb Eric Charles:
> Hi Tim,
>
> So there is consensus to leave the package naming as-is and move
> entities with openjpa proprietary extension to the openjpa packages.
>
> Currently, I have no well defined patch (only many trials I made).
> I will implement some @ElementJoinColumn and @Index and test it with
> real traffic.
> Depending on the result and timing, we may integrate the changes in our
> upcoming 3.0 M1 release.
>
> I will also need to upgrade the current database schema and datas.
> Probably the number of users that need this migration is very limited
> (only users running a 3.0 trunk built snapshot).
> However, we could use it as a base for the latter migrations and also
> for the 2.3 to 3.0 migration.
> I will look if an existing JIRA or create a new one to publish the progress.
>
> Tks,
>
> Eric
>
>
> On 06/26/2010 10:17 AM, Tim-Christian Mundt wrote:
> > Hi Norman and Eric,
> >
> > I fully agree with simply using OpenJPA annotations.
> >
> > Concerning the openjpa package I think I found what you mean, Eric. It
> > was confusing because there are two OpenJPA packages:
> > org/apache/james/imap/jpa/mail/model/openjpa
> > org/apache/james/imap/jpa/openjpa
> >
> > The latter is there merely to support the "useStreaming" option, if I
> > don't err. The former is also for streaming, so yes, it would make sense
> > to rename it. On the other hand we could move all OpenJPA stuff
> > to /jpa/openjpa which would basically mean to e.g. put the streaming
> > classes into
> > org/apache/james/imap/jpa/openjpa/mail/model/streaming
> > If everything with proprietary OpenJPA annotations would be in a
> > separate package it would become immediate which classes one needs to
> > implement in order to create a new provider. That's my vote: stick with
> > OpenJPA but still cleanly separate it from standards conforming code.
> >
> > Eric, could you send us a patch of what you've done so far? Then we can
> > finish it (hope you still read this before your trip...)
> >
> > Tim
> >
> > Am Freitag, den 25.06.2010, 19:33 +0200 schrieb Norman Maurer:
> >
> >> Ok so to come to some consequence here.. Let us just use the openjpa
> >> annotation stuff.. If we really want to support other JPA
> >> implementations we could handle it later..
> >>
> >> Bye,
> >> Norman
> >>
> >>
> >> 2010/6/25 Tim-Christian Mundt<de...@tim-erwin.de>:
> >>
> >>> Hey,
> >>>
> >>>
> >>>
> >>>> I'm also happy with OpenJPA and using its proprietary annotations (not
> >>>> classes) doesn't prohibit a developer/deployer to define another JPA
> >>>> provider.
> >>>>
> >>> Right.
> >>>
> >>>
> >>>> What about :
> >>>> - @ElementJoinColumn ?
> >>>> - @Index ?
> >>>>
> >>> I'd support those.
> >>>
> >>>
> >>>> - rename 'openjpa' package to 'streaming' ?
> >>>>
> >>> We already have a streaming package and there is both streaming and
> >>> non-streaming for OpenJPA, so why rename the package? Maybe I haven't
> >>> fully understood your point.
> >>>
> >>>
> >>>> I will be off for 2 weeks and won't probably be able to continue the
> >>>> conversation.
> >>>>
> >>> Hope I may say "Happy vacations" :)
> >>>
> >>> Best
> >>> Tim
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >>> For additional commands, e-mail: server-dev-help@james.apache.org
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >> For additional commands, e-mail: server-dev-help@james.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JPA for imap 0.1 release
Posted by Norman Maurer <no...@apache.org>.
You need to rename the mailbox names too:
https://issues.apache.org/jira/browse/IMAP-176
We changed #mail to #private.
Bye,
Norman
2010/7/12 Tim-Christian Mundt <de...@tim-erwin.de>:
> Hi Eric,
>
> sorry, I forgot IMAP-172. Besides that I don't know of any impacts.
>
> Tim
>
> Am Sonntag, den 11.07.2010, 19:45 +0200 schrieb Eric Charles:
>> Hi Tim,
>>
>> I still need time to find my way in the hard-work you did with Norman
>> these last 2 weeks :)
>> Upon IMAP-168, are there other JIRA that could impact the database
>> schema/data (IMAP-172,...?) ?
>> Tks,
>> Eric
>>
>>
>> On 07/11/2010 03:12 PM, Tim-Christian Mundt wrote:
>> > Hi Eric,
>> >
>> > that sounds good. Let's see, if we can provide a sql-only migration
>> > script. After solving issue IMAP-168 the database schema will change
>> > again, so we'll have to take care of that, too.
>> >
>> > Best
>> > Tim
>> >
>> > Am Sonntag, den 11.07.2010, 14:18 +0200 schrieb Eric Charles:
>> >
>> >> Hi Tim,
>> >>
>> >> So there is consensus to leave the package naming as-is and move
>> >> entities with openjpa proprietary extension to the openjpa packages.
>> >>
>> >> Currently, I have no well defined patch (only many trials I made).
>> >> I will implement some @ElementJoinColumn and @Index and test it with
>> >> real traffic.
>> >> Depending on the result and timing, we may integrate the changes in our
>> >> upcoming 3.0 M1 release.
>> >>
>> >> I will also need to upgrade the current database schema and datas.
>> >> Probably the number of users that need this migration is very limited
>> >> (only users running a 3.0 trunk built snapshot).
>> >> However, we could use it as a base for the latter migrations and also
>> >> for the 2.3 to 3.0 migration.
>> >> I will look if an existing JIRA or create a new one to publish the progress.
>> >>
>> >> Tks,
>> >>
>> >> Eric
>> >>
>> >>
>> >> On 06/26/2010 10:17 AM, Tim-Christian Mundt wrote:
>> >>
>> >>> Hi Norman and Eric,
>> >>>
>> >>> I fully agree with simply using OpenJPA annotations.
>> >>>
>> >>> Concerning the openjpa package I think I found what you mean, Eric. It
>> >>> was confusing because there are two OpenJPA packages:
>> >>> org/apache/james/imap/jpa/mail/model/openjpa
>> >>> org/apache/james/imap/jpa/openjpa
>> >>>
>> >>> The latter is there merely to support the "useStreaming" option, if I
>> >>> don't err. The former is also for streaming, so yes, it would make sense
>> >>> to rename it. On the other hand we could move all OpenJPA stuff
>> >>> to /jpa/openjpa which would basically mean to e.g. put the streaming
>> >>> classes into
>> >>> org/apache/james/imap/jpa/openjpa/mail/model/streaming
>> >>> If everything with proprietary OpenJPA annotations would be in a
>> >>> separate package it would become immediate which classes one needs to
>> >>> implement in order to create a new provider. That's my vote: stick with
>> >>> OpenJPA but still cleanly separate it from standards conforming code.
>> >>>
>> >>> Eric, could you send us a patch of what you've done so far? Then we can
>> >>> finish it (hope you still read this before your trip...)
>> >>>
>> >>> Tim
>> >>>
>> >>> Am Freitag, den 25.06.2010, 19:33 +0200 schrieb Norman Maurer:
>> >>>
>> >>>
>> >>>> Ok so to come to some consequence here.. Let us just use the openjpa
>> >>>> annotation stuff.. If we really want to support other JPA
>> >>>> implementations we could handle it later..
>> >>>>
>> >>>> Bye,
>> >>>> Norman
>> >>>>
>> >>>>
>> >>>> 2010/6/25 Tim-Christian Mundt<de...@tim-erwin.de>:
>> >>>>
>> >>>>
>> >>>>> Hey,
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> I'm also happy with OpenJPA and using its proprietary annotations (not
>> >>>>>> classes) doesn't prohibit a developer/deployer to define another JPA
>> >>>>>> provider.
>> >>>>>>
>> >>>>>>
>> >>>>> Right.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> What about :
>> >>>>>> - @ElementJoinColumn ?
>> >>>>>> - @Index ?
>> >>>>>>
>> >>>>>>
>> >>>>> I'd support those.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> - rename 'openjpa' package to 'streaming' ?
>> >>>>>>
>> >>>>>>
>> >>>>> We already have a streaming package and there is both streaming and
>> >>>>> non-streaming for OpenJPA, so why rename the package? Maybe I haven't
>> >>>>> fully understood your point.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> I will be off for 2 weeks and won't probably be able to continue the
>> >>>>>> conversation.
>> >>>>>>
>> >>>>>>
>> >>>>> Hope I may say "Happy vacations" :)
>> >>>>>
>> >>>>> Best
>> >>>>> Tim
>> >>>>>
>> >>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> >>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> >>>> For additional commands, e-mail: server-dev-help@james.apache.org
>> >>>>
>> >>>>
>> >>>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> >>> For additional commands, e-mail: server-dev-help@james.apache.org
>> >>>
>> >>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> >> For additional commands, e-mail: server-dev-help@james.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> > For additional commands, e-mail: server-dev-help@james.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JPA for imap 0.1 release
Posted by Tim-Christian Mundt <de...@tim-erwin.de>.
Hi Eric,
sorry, I forgot IMAP-172. Besides that I don't know of any impacts.
Tim
Am Sonntag, den 11.07.2010, 19:45 +0200 schrieb Eric Charles:
> Hi Tim,
>
> I still need time to find my way in the hard-work you did with Norman
> these last 2 weeks :)
> Upon IMAP-168, are there other JIRA that could impact the database
> schema/data (IMAP-172,...?) ?
> Tks,
> Eric
>
>
> On 07/11/2010 03:12 PM, Tim-Christian Mundt wrote:
> > Hi Eric,
> >
> > that sounds good. Let's see, if we can provide a sql-only migration
> > script. After solving issue IMAP-168 the database schema will change
> > again, so we'll have to take care of that, too.
> >
> > Best
> > Tim
> >
> > Am Sonntag, den 11.07.2010, 14:18 +0200 schrieb Eric Charles:
> >
> >> Hi Tim,
> >>
> >> So there is consensus to leave the package naming as-is and move
> >> entities with openjpa proprietary extension to the openjpa packages.
> >>
> >> Currently, I have no well defined patch (only many trials I made).
> >> I will implement some @ElementJoinColumn and @Index and test it with
> >> real traffic.
> >> Depending on the result and timing, we may integrate the changes in our
> >> upcoming 3.0 M1 release.
> >>
> >> I will also need to upgrade the current database schema and datas.
> >> Probably the number of users that need this migration is very limited
> >> (only users running a 3.0 trunk built snapshot).
> >> However, we could use it as a base for the latter migrations and also
> >> for the 2.3 to 3.0 migration.
> >> I will look if an existing JIRA or create a new one to publish the progress.
> >>
> >> Tks,
> >>
> >> Eric
> >>
> >>
> >> On 06/26/2010 10:17 AM, Tim-Christian Mundt wrote:
> >>
> >>> Hi Norman and Eric,
> >>>
> >>> I fully agree with simply using OpenJPA annotations.
> >>>
> >>> Concerning the openjpa package I think I found what you mean, Eric. It
> >>> was confusing because there are two OpenJPA packages:
> >>> org/apache/james/imap/jpa/mail/model/openjpa
> >>> org/apache/james/imap/jpa/openjpa
> >>>
> >>> The latter is there merely to support the "useStreaming" option, if I
> >>> don't err. The former is also for streaming, so yes, it would make sense
> >>> to rename it. On the other hand we could move all OpenJPA stuff
> >>> to /jpa/openjpa which would basically mean to e.g. put the streaming
> >>> classes into
> >>> org/apache/james/imap/jpa/openjpa/mail/model/streaming
> >>> If everything with proprietary OpenJPA annotations would be in a
> >>> separate package it would become immediate which classes one needs to
> >>> implement in order to create a new provider. That's my vote: stick with
> >>> OpenJPA but still cleanly separate it from standards conforming code.
> >>>
> >>> Eric, could you send us a patch of what you've done so far? Then we can
> >>> finish it (hope you still read this before your trip...)
> >>>
> >>> Tim
> >>>
> >>> Am Freitag, den 25.06.2010, 19:33 +0200 schrieb Norman Maurer:
> >>>
> >>>
> >>>> Ok so to come to some consequence here.. Let us just use the openjpa
> >>>> annotation stuff.. If we really want to support other JPA
> >>>> implementations we could handle it later..
> >>>>
> >>>> Bye,
> >>>> Norman
> >>>>
> >>>>
> >>>> 2010/6/25 Tim-Christian Mundt<de...@tim-erwin.de>:
> >>>>
> >>>>
> >>>>> Hey,
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> I'm also happy with OpenJPA and using its proprietary annotations (not
> >>>>>> classes) doesn't prohibit a developer/deployer to define another JPA
> >>>>>> provider.
> >>>>>>
> >>>>>>
> >>>>> Right.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> What about :
> >>>>>> - @ElementJoinColumn ?
> >>>>>> - @Index ?
> >>>>>>
> >>>>>>
> >>>>> I'd support those.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> - rename 'openjpa' package to 'streaming' ?
> >>>>>>
> >>>>>>
> >>>>> We already have a streaming package and there is both streaming and
> >>>>> non-streaming for OpenJPA, so why rename the package? Maybe I haven't
> >>>>> fully understood your point.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> I will be off for 2 weeks and won't probably be able to continue the
> >>>>>> conversation.
> >>>>>>
> >>>>>>
> >>>>> Hope I may say "Happy vacations" :)
> >>>>>
> >>>>> Best
> >>>>> Tim
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >>>>> For additional commands, e-mail: server-dev-help@james.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >>>> For additional commands, e-mail: server-dev-help@james.apache.org
> >>>>
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >>> For additional commands, e-mail: server-dev-help@james.apache.org
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >> For additional commands, e-mail: server-dev-help@james.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JPA for imap 0.1 release
Posted by Eric Charles <er...@apache.org>.
Hi Tim,
I still need time to find my way in the hard-work you did with Norman
these last 2 weeks :)
Upon IMAP-168, are there other JIRA that could impact the database
schema/data (IMAP-172,...?) ?
Tks,
Eric
On 07/11/2010 03:12 PM, Tim-Christian Mundt wrote:
> Hi Eric,
>
> that sounds good. Let's see, if we can provide a sql-only migration
> script. After solving issue IMAP-168 the database schema will change
> again, so we'll have to take care of that, too.
>
> Best
> Tim
>
> Am Sonntag, den 11.07.2010, 14:18 +0200 schrieb Eric Charles:
>
>> Hi Tim,
>>
>> So there is consensus to leave the package naming as-is and move
>> entities with openjpa proprietary extension to the openjpa packages.
>>
>> Currently, I have no well defined patch (only many trials I made).
>> I will implement some @ElementJoinColumn and @Index and test it with
>> real traffic.
>> Depending on the result and timing, we may integrate the changes in our
>> upcoming 3.0 M1 release.
>>
>> I will also need to upgrade the current database schema and datas.
>> Probably the number of users that need this migration is very limited
>> (only users running a 3.0 trunk built snapshot).
>> However, we could use it as a base for the latter migrations and also
>> for the 2.3 to 3.0 migration.
>> I will look if an existing JIRA or create a new one to publish the progress.
>>
>> Tks,
>>
>> Eric
>>
>>
>> On 06/26/2010 10:17 AM, Tim-Christian Mundt wrote:
>>
>>> Hi Norman and Eric,
>>>
>>> I fully agree with simply using OpenJPA annotations.
>>>
>>> Concerning the openjpa package I think I found what you mean, Eric. It
>>> was confusing because there are two OpenJPA packages:
>>> org/apache/james/imap/jpa/mail/model/openjpa
>>> org/apache/james/imap/jpa/openjpa
>>>
>>> The latter is there merely to support the "useStreaming" option, if I
>>> don't err. The former is also for streaming, so yes, it would make sense
>>> to rename it. On the other hand we could move all OpenJPA stuff
>>> to /jpa/openjpa which would basically mean to e.g. put the streaming
>>> classes into
>>> org/apache/james/imap/jpa/openjpa/mail/model/streaming
>>> If everything with proprietary OpenJPA annotations would be in a
>>> separate package it would become immediate which classes one needs to
>>> implement in order to create a new provider. That's my vote: stick with
>>> OpenJPA but still cleanly separate it from standards conforming code.
>>>
>>> Eric, could you send us a patch of what you've done so far? Then we can
>>> finish it (hope you still read this before your trip...)
>>>
>>> Tim
>>>
>>> Am Freitag, den 25.06.2010, 19:33 +0200 schrieb Norman Maurer:
>>>
>>>
>>>> Ok so to come to some consequence here.. Let us just use the openjpa
>>>> annotation stuff.. If we really want to support other JPA
>>>> implementations we could handle it later..
>>>>
>>>> Bye,
>>>> Norman
>>>>
>>>>
>>>> 2010/6/25 Tim-Christian Mundt<de...@tim-erwin.de>:
>>>>
>>>>
>>>>> Hey,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I'm also happy with OpenJPA and using its proprietary annotations (not
>>>>>> classes) doesn't prohibit a developer/deployer to define another JPA
>>>>>> provider.
>>>>>>
>>>>>>
>>>>> Right.
>>>>>
>>>>>
>>>>>
>>>>>> What about :
>>>>>> - @ElementJoinColumn ?
>>>>>> - @Index ?
>>>>>>
>>>>>>
>>>>> I'd support those.
>>>>>
>>>>>
>>>>>
>>>>>> - rename 'openjpa' package to 'streaming' ?
>>>>>>
>>>>>>
>>>>> We already have a streaming package and there is both streaming and
>>>>> non-streaming for OpenJPA, so why rename the package? Maybe I haven't
>>>>> fully understood your point.
>>>>>
>>>>>
>>>>>
>>>>>> I will be off for 2 weeks and won't probably be able to continue the
>>>>>> conversation.
>>>>>>
>>>>>>
>>>>> Hope I may say "Happy vacations" :)
>>>>>
>>>>> Best
>>>>> Tim
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org