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 <[EMAIL PROTECTED]> wrote:
On Aug 8, 2006, at 3:47 PM, Aaron Mulder wrote:
> On 8/8/06, David Blevins <[EMAIL PROTECTED]> 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
