geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Date Wed, 09 Aug 2006 08:21:52 GMT
Personally, I'm happy that Aaron still wants to work on Geronimo at  
all.  If he wants to work out on SourceForge, that's really his  
decision no matter what the reasons.  I don't see an upside to  
pushing the topic.

As long as he doesn't get upset that others are working on  
potentially the same thing inside Geronimo, then we're in good shape.

Hey Aaron, I'm going to start a branch tomorrow to experiment with  
JPA stuff, you and your crew are obviously welcome to play in my  
sandbox :)  Regardless, I really like the discussion we're having --  
helps keep me focused and I like comparing notes.

Best case scenario, we end up with some excellent JPA functionality  
for 1.1 and 1.2 as well as plugins for ASL and GPL JPA providers.

These are things users need badly.  Good goals.

-David

On Aug 8, 2006, at 10:34 PM, Kevan Miller wrote:

> Aaron,
> I didn't disagree with your conclusion. You gave 3 reasons for not  
> performing the work at Apache. All you needed was one -- licensing  
> issues prevent this work from occurring at Apache. Maybe so, but so  
> far only you have made that evaluation. I'm not intimating that you  
> are wrong, only that, to my knowledge, it hasn't been discussed...
>
> You gave two additional reasons for not performing the work at  
> Apache. I commented on those two reasons. The rest inline...
>
> On Aug 8, 2006, at 5:52 PM, Aaron Mulder wrote:
>
>> On 8/8/06, Kevan Miller <kevan.miller@gmail.com> wrote:
>>>
>>> On Aug 8, 2006, at 3:47 PM, Aaron Mulder wrote:
>>>
>>> > On 8/8/06, David Blevins <david.blevins@visi.com> wrote:
>>> >> So who is we and why SourceForge?  I can certainly see having
>>> >> Hibernate provider plugins and stuff there, but I definitely  
>>> intend
>>> >> on writing the core bits in Geronimo svn.
>>> >
>>> > "we" is myself and some folks at Chariot.  At SourceForge  
>>> because 1)
>>> > we need some place to collaborate on the code and that's  
>>> impossible
>>> > under RTC, 2) we are working primarily with TopLink during  
>>> development
>>> > and that's impossible at Apache, 3) it was easier to set up a
>>> > SourceForge project than Codehaus and I don't know what to make of
>>> > Google, and 4) I was explicitly told that plugin development  
>>> should be
>>> > done outside of Apache.
>>>
>>> Regarding 1) -- too bad you feel this way.
>>
>> Well, how would you recommend working on new features with others?
>> Normally you commit when you're at a point that you want to share and
>> then others can update.  Under RTC, you have to post to a Jira and
>> propose a vote and get 3 PMC members on board before anyone else can
>> update.  So really, it's collaboration via pasting patches to Jira.
>> That's ridiculous.  The next alternative is a branch.  I've seen Dain
>> and Jason do the branch thing, and it looked to me like they spent as
>> much time trying to keep the branch in sync with trunk as actually
>> working on the branch.  No thanks.  So what do you recommend?  Do
>> everything in the sandbox?
>
> So, which is it? Do you want the code to come to Geronimo, or not?  
> If you do, then I suggest you work with the community in realizing  
> that. Communicate your plans, discuss your ideas, and follow the  
> community process for contributing code.
>
>
>>
>>> Regarding 4) -- that's news to me and I can see no reason why that
>>> would be true.
>>
>> Please, enlighten me as to how we can work with TopLink and Hibernate
>> within the context of Geronimo?  Are we allowed to include GPL  
>> modules
>> in the build now?  And how do I work with people who have cycles to
>> contribute but aren't committers?  Are we back to collaboration via
>> patches on Jira?  Also, how about the fact that Matt and Alan have
>> remained firmly opposed to new features in the 1.1 branch.  So where
>> do you recommend we develop JPA for Geronimo 1.1?  Sandbox?
>
> You said "4) I was explicitly told that plugin development should  
> be done outside of Apache". This implies that no plugin should ever  
> be implemented within Apache. I wasn't questioning the specifics of  
> your case, I was questioning the generalities of that statement. I  
> can see no reason why it would be true.
>
> I agree with Matt and Alan, but why would a plugin need to be  
> within the 1.1 branch? How about geronimo/plugins/app-jpa/trunk? Or  
> initially, sandbox/app-jpa/trunk?
>
>>
>> Look, you have to admit, it's not realistic for all Geronimo-related
>> development to be done within the context of Geronimo.  ActiveMQ,
>> OpenEJB, and TranQL have gone forever as independent projects, Jencks
>> and WebSphere CE are heavily leveraging Geronimo, LifeRay and Apache
>> Directory are certainly not developing their stuff at
>> geronimo.apache.org, I could give 20 examples.
>
> Yes, and World Hunger is a bad thing. I never said that your plugin  
> should be developed at Apache. I just questioned some of the  
> reasons why you said it *could* not be developed at Apache.
>
>>
>> Please list the advantages of developing plugins inside the Geronimo
>> project.  To me, plugins are best developed elsewhere, and what we
>> learn developing the plugins should feed ideas for improvements into
>> the core product, so it can better support a wider variety of plugins
>> in the future.
>
> Advantages? Well, that would be whatever the skills, knowledge, and  
> dedication of the community can contribute. Also, it seems like  
> communication would be more efficient with work occurring within  
> the community, not outside.
>
> That said, there are perfectly valid personal, technical, and legal  
> reasons for plugin work to occur outside of Geronimo. RTC and "no  
> plugins at apache" are not good reasons, IMO...
>
> --kevan
>
>
>>
>> Thanks,
>>     Aaron
>>
>>> >> Nothing other than I intend to try and hook the main deployers
>>> >> similarly to the way we did for processing the  
>>> webservice.xml.  Aka,
>>> >> whip up some interface, hard code the deployers to call it at a
>>> >> logical point in the deployment process.
>>> >
>>> > We're targeting Geronimo 1.1, which means we only have what we  
>>> have,
>>> > and I think I have to do it the ugly way.
>>> >
>>> > If we're talking about future releases, I strongly oppose adding
>>> > another hardcoded "deployment helper".  I think we need a  
>>> generic list
>>> > of auxilliary deployers that can get invoked every time a J2EE
>>> > application module is deployed.  For example, the Quartz plugin  
>>> lets
>>> > you include scheduled jobs in a WAR and so it needs to hook  
>>> into the
>>> > WAR deployment process too.  As long as we have all these various
>>> > things that want to do that, let's make it pluggable.
>>> >
>>> >> I like the naming convention.  There is a JNDI context attribute
>>> >> essentially on each EjbDeployment object -- think OpenEJB  
>>> 1.0.  In
>>> >> the related EjbDeployment GBean it's called  
>>> "componentContextMap" and
>>> >> it's simply a Map that's converted to an ENC via a call to
>>> >> "EnterpriseNamingContext.createEnterpriseNamingContext"
>>> >
>>> > OK, that sounds easy enough.  But if you have one
>>> > META-INF/persistence.xml file in your EJB JAR, how do you know  
>>> which
>>> > EJBs should get the JNDI entries?  Or is there some convention  
>>> to map
>>> > individual EJBs to differently-named persistence.xml files, or  
>>> to map
>>> > persistence units in persistence.xml to individual EJBs?
>>> >
>>> >> Sure.  You only attempting to do Application-Managed JPA support
>>> >> (EntityManagerFactory objects in JNDI ENCs), so the plugin  
>>> approach
>>> >> will work fine.  When it comes to Container-Managed JPA support
>>> >> (proxied EntityManagers in JNDI, tracked by connections and  
>>> enrolled
>>> >> in the transaction context), you're going to have a tougher  
>>> time.  At
>>> >> that point we're more likely to start by taking the connector  
>>> support
>>> >> and expanding it to include JPA.
>>> >
>>> > Yeah, not targeting container-managed JPA support with this  
>>> plugin.
>>> >
>>> > We are using a Geronimo DB pool for persistence, though.  So  
>>> doesn't
>>> > that mean it would be included in any transaction that was  
>>> going on
>>> > already?  Not too relevant for web apps, but would JPA in a  
>>> Session
>>> > Bean inherit the Session Bean transaction settings?  I'm not  
>>> sure at
>>> > what point in the process the DataSource or Connection notices  
>>> that
>>> > there's a transaction going on and enlists itself.
>>> >
>>> > Thanks,
>>> >      Aaron
>>>
>>>
>


Mime
View raw message