You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Brian McCallister <mc...@forthillcompany.com> on 2003/11/12 16:03:51 UTC

XDoclet Module (and other tools)

I have been in discussion with Thomas Dudziak (OJB XDoclet module 
developer), Erik Hatcher (XDoclet (and Ant)), and Andrew Stevens 
(XDoclet) trying to find a home for Thomas's work.

Erik and Andrew both feel that the best place is in the OJB repository, 
or rather, outside of XDoclet as the XDoclet team is apparently trying 
to push all the "included" modules out and get the various vendors to 
maintain them directly. Andrew indicated that he would be willing to 
check it in for the 1.X branch, but that the 1.X branch isn't going to 
be around past the next release -- and for 2.0 they are apparently 
trying to push the vendor specific (which OJB falls under) modules back 
out to the vendors to maintain and only include core stuff (generic 
EJB, servlet, etc, I imagine) in their repository.

Right now we are keeping a jar in the contrib project of our cvs 
repository -- I would like to find a place to put the source under CVS 
as well. I think that helping keep tool support up to date and easily 
available is important for OJB's larger acceptance, so we should think 
about this some.

As the number of tools in the OJB repository is growing I think it 
might be good to consider their appropriate homes. This includes the 
reversedb, xdoclet module, middlegen module, etc.

So, some options that I see:

1) Create a tools CVS module under OJB and give them their own build 
chain(s).
2) Create an ojb-tools project analogous to velocity-tools
3) Host at java.net or SF and prominently advertise them on the OJB site

2 doesn't seem completely appropriate
1 keeps communication open and makes it easier to distribute things 
en-masse
3 allows for easier licensing flexibility for things like the OSCache 
ObjectCache

-Brian

PS: I use the XDoclet module at work and it is great =)



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: XDoclet Module (and other tools)

Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Thomas Mahler dijo:
> Hi all,
>
> Brian McCallister wrote:
> <snip intro>
>>
>> So, some options that I see:
>>
>> 1) Create a tools CVS module under OJB and give them their own build
>> chain(s).
>
> +1 for the OJB XDoclet module! I think the focus of that code is close
> enough to the OJB code that we can host it.

I also thought about let Druid generate XDoclet comments in Java. Sounds
this great?

When I will find time I will this too. :-D

Best Regards,

Antonio Gallardo


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: XDoclet Module (and other tools)

Posted by Thomas Mahler <th...@web.de>.
Hi all,

Brian McCallister wrote:
<snip intro>
> 
> So, some options that I see:
> 
> 1) Create a tools CVS module under OJB and give them their own build 
> chain(s).

+1 for the OJB XDoclet module! I think the focus of that code is close 
enough to the OJB code that we can host it.

I suggest to keept it under /src/tools/xdoclet or under 
/src/java/org.apache.ojb/tools/xdoclet (the latter would require to 
change package names for the existing code).

> 2) Create an ojb-tools project analogous to velocity-tools

-1  (I don't like to split evything into sub-sub-sub projects)

> 3) Host at java.net or SF and prominently advertise them on the OJB site

This can be an option for tools that have a scope that is not that close 
to the OJB core or that have a different license model.

cu,
Thomas

> 2 doesn't seem completely appropriate
> 1 keeps communication open and makes it easier to distribute things 
> en-masse
> 3 allows for easier licensing flexibility for things like the OSCache 
> ObjectCache
> 
> -Brian
> 
> PS: I use the XDoclet module at work and it is great =)
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: XDoclet Module (and other tools)

Posted by Thomas Dudziak <to...@first.gmd.de>.

On Thu, 13 Nov 2003, Brian McCallister wrote:

> 
> On Thursday, November 13, 2003, at 01:44 AM, Thomas Mahler wrote:
> > If Thomas (D) is willing I propose to give him committer status so 
> > that he can work directly on the CVS repository.
> >
> 
> +1 Though "Thomas" will become awfully confusing =)

That's one of the reasons why I prefer Tom instead of Thomas since school
(and its shorter, too ;-)

Tom



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: XDoclet Module (and other tools)

Posted by Brian McCallister <mc...@forthillcompany.com>.
On Thursday, November 13, 2003, at 01:44 AM, Thomas Mahler wrote:
> If Thomas (D) is willing I propose to give him committer status so 
> that he can work directly on the CVS repository.
>

+1 Though "Thomas" will become awfully confusing =)

-Brian



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: XDoclet Module (and other tools)

Posted by Thomas Mahler <th...@web.de>.
Hi,

Brian McCallister wrote:
> On Wednesday, November 12, 2003, at 11:41 AM, Armin Waibel wrote:
> 
>> .So, some options that I see:
>>
>>> 1) Create a tools CVS module under OJB and give them their own build 
>>> chain(s).
> 
> snip
> 
>> +1 for 1), provided that we found some people keep
>> xdoclet modul in sync with OJB ;-)
>>
> 
> Thomas, you willing?

If Thomas (D) is willing I propose to give him committer status so that 
he can work directly on the CVS repository.

-Thomas (M)

> -Brian
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: XDoclet Module (and other tools)

Posted by Brian McCallister <mc...@forthillcompany.com>.
On Wednesday, November 12, 2003, at 03:13 PM, Thomas Dudziak wrote:
> (Hope you meant me ;-)
>
> Tom
>

Hmm, methinks that this means you are forthwith dubbed "Tom" instead of 
"Thomas" =)

-Brian (not Behlendorf)



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: XDoclet Module (and other tools)

Posted by Thomas Dudziak <to...@first.gmd.de>.

On Wed, 12 Nov 2003, Brian McCallister wrote:

> On Wednesday, November 12, 2003, at 11:41 AM, Armin Waibel wrote:
> > .So, some options that I see:
> >> 1) Create a tools CVS module under OJB and give them their own build 
> >> chain(s).
> snip
> > +1 for 1), provided that we found some people keep
> > xdoclet modul in sync with OJB ;-)
> >
> 
> Thomas, you willing?

Sure, that's what I'm currently doing, anyway. (Hope you meant me ;-)

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: XDoclet Module (and other tools)

Posted by Brian McCallister <mc...@forthillcompany.com>.
On Wednesday, November 12, 2003, at 11:41 AM, Armin Waibel wrote:
> .So, some options that I see:
>> 1) Create a tools CVS module under OJB and give them their own build 
>> chain(s).
snip
> +1 for 1), provided that we found some people keep
> xdoclet modul in sync with OJB ;-)
>

Thomas, you willing?

-Brian



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: XDoclet Module (and other tools)

Posted by Armin Waibel <ar...@code-au-lait.de>.
Hi Brian,

Brian McCallister wrote:

...
> So, some options that I see:
> 
> 1) Create a tools CVS module under OJB and give them their own build 
> chain(s).
> 2) Create an ojb-tools project analogous to velocity-tools
> 3) Host at java.net or SF and prominently advertise them on the OJB site
> 
> 2 doesn't seem completely appropriate
> 1 keeps communication open and makes it easier to distribute things 
> en-masse
> 3 allows for easier licensing flexibility for things like the OSCache 
> ObjectCache
> 
+1 for 1), provided that we found some people keep
xdoclet modul in sync with OJB ;-)

Armin

> -Brian
> 
> PS: I use the XDoclet module at work and it is great =)
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: XDoclet Module (and other tools)

Posted by Thomas Dudziak <to...@first.gmd.de>.
> Erik and Andrew both feel that the best place is in the OJB repository, 
> or rather, outside of XDoclet as the XDoclet team is apparently trying 
> to push all the "included" modules out and get the various vendors to 
> maintain them directly. Andrew indicated that he would be willing to 
> check it in for the 1.X branch, but that the 1.X branch isn't going to 
> be around past the next release -- and for 2.0 they are apparently 
> trying to push the vendor specific (which OJB falls under) modules back 
> out to the vendors to maintain and only include core stuff (generic 
> EJB, servlet, etc, I imagine) in their repository.


This seems like a reasonable notion as it would shift the maintenance to
the people that actually use the module (e.g. the JBoss, TJDO, ... people
ensure that the xdoclet module for them work). Also this allows for a
better build/release schedule as the module development should have higher
performance than the complete xdoclet tree.


> Right now we are keeping a jar in the contrib project of our cvs 
> repository -- I would like to find a place to put the source under CVS 
> as well. I think that helping keep tool support up to date and easily 
> available is important for OJB's larger acceptance, so we should think 
> about this some.
> 
> As the number of tools in the OJB repository is growing I think it 
> might be good to consider their appropriate homes. This includes the 
> reversedb, xdoclet module, middlegen module, etc.
> 
> So, some options that I see:
> 
> 1) Create a tools CVS module under OJB and give them their own build 
> chain(s).
> 2) Create an ojb-tools project analogous to velocity-tools
> 3) Host at java.net or SF and prominently advertise them on the OJB site
> 
> 2 doesn't seem completely appropriate
> 1 keeps communication open and makes it easier to distribute things 
> en-masse
> 3 allows for easier licensing flexibility for things like the OSCache 
> ObjectCache


I don't know about the velocity-tools project, so I cannot say
much about option 2. As for options 1 and 3, the major difference
(ignoring technical and infrastructural aspects) is the level of
association to OJB. When tools are hosted by OJB, then they are tied to
OJB, e.g. people with problems will call for help on the OJB mailing
lists. If they are related projects but on SF or elsewhere, they probably
have to and will ask on the respective mailing lists and forums there. So
I guess both options are reasonable.
For instance, I'd say the xdoclet module is rather tightly related to OJB,
so hosting it on OJB makes sense to me. Whereas tools in the direction of
Druid (which is of course not OJB specific, but anyway) should "only" be
heavily advertised on OJB, but not integrated into the CVS tree of OJB.
Of course, there already are projects tightly related to OJB outside of
the OJB CVS. At least one, the OJB console (http://ojbc.sourceforge.net),
comes to my mind. Perhaps the developers of this project can say
something about which option is better ?

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


RE: XDoclet Module (and other tools)

Posted by Reinhard Poetz <re...@apache.org>.
From: Brian McCallister

> I have been in discussion with Thomas Dudziak (OJB XDoclet module 
> developer), Erik Hatcher (XDoclet (and Ant)), and Andrew Stevens 
> (XDoclet) trying to find a home for Thomas's work.
> 
> Erik and Andrew both feel that the best place is in the OJB 
> repository, 
> or rather, outside of XDoclet as the XDoclet team is 
> apparently trying 
> to push all the "included" modules out and get the various vendors to 
> maintain them directly. Andrew indicated that he would be willing to 
> check it in for the 1.X branch, but that the 1.X branch isn't 
> going to 
> be around past the next release -- and for 2.0 they are apparently 
> trying to push the vendor specific (which OJB falls under) 
> modules back 
> out to the vendors to maintain and only include core stuff (generic 
> EJB, servlet, etc, I imagine) in their repository.
> 
> Right now we are keeping a jar in the contrib project of our cvs 
> repository -- I would like to find a place to put the source 
> under CVS 
> as well. I think that helping keep tool support up to date and easily 
> available is important for OJB's larger acceptance, so we 
> should think 
> about this some.
> 
> As the number of tools in the OJB repository is growing I think it 
> might be good to consider their appropriate homes. This includes the 
> reversedb, xdoclet module, middlegen module, etc.
> 
> So, some options that I see:
> 
> 1) Create a tools CVS module under OJB and give them their own build 
> chain(s).
> 2) Create an ojb-tools project analogous to velocity-tools
> 3) Host at java.net or SF and prominently advertise them on 
> the OJB site
> 
> 2 doesn't seem completely appropriate
> 1 keeps communication open and makes it easier to distribute things 
> en-masse
> 3 allows for easier licensing flexibility for things like the OSCache 
> ObjectCache

According to https://oscache.dev.java.net/ OSCache is licensed using the
ASL. Which kind of flexibility do you gain if the XDoclet-OJB-module is
hosted at sf.net or java.net? (Of course it would make sense if OSCache
would be under LGPL ...)

In my opinion option 1) would be the way to go from a user POV because
if I download OJB I want to get all the tools which make my life easier
and XDoclet support is such a tool! This also guarantees that OJB core
and the XDoclet module do not get out of sync.

Regards,
Reinhard



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org