From: Jose G. G. <jgo...@op...> - 2004-11-29 12:28:27
|
Hi there, Recently I came across http://xdoclet.codehaus.org/ and found that XDoclet2 seems to be in a rather usable state. Any way, there is no information in the web about status of the project, expected release dates, downloadable source or binary tarballs or anything like that... what is the status of the project? Do you recommend a migration to XDoclet2 in its current state? Is it possible to use with the current release of Maven? Best regards Jose |
From: Konstantin P. <kpr...@ya...> - 2004-11-29 12:34:57
|
--- Jose Gonzalez Gomez <jgo...@op...> wrote: > > Hi there, > > Recently I came across > http://xdoclet.codehaus.org/ and found that > XDoclet2 seems to be in a rather usable state. Yes , it is. > Any > way, there is no > information in the web about status of the project, > expected release > dates, downloadable source or binary tarballs or > anything like that... 2.0 is released and is in codehaus repository. JIRA / Sources are also there. Maven takes care about downloading. Though yuo do not need much infotmation about xdoclet itself, it's plugins which do the job ( http://www.sourceforge.net/projects/xdoclet-plugins/ ) > what is the status of the project? Do you recommend > a migration to > XDoclet2 in its current state? It depends on what you need. Hibernate plugin is in pretty good shape. EJB stuff is kind of orphaned. >Is it possible to use > with the current > release of Maven? Yes. regards, ===== ----[ Konstantin Pribluda ( ko5tik ) ]---------------- ... Sucht gerade nach neuen Projekt oder Festanstelung.... Plugins for xdoclet-2 are released. check it out at: http://www.sourceforge.net/projects/xdoclet-plugins/ ----[ http://www.pribluda.de ]------------------------ __________________________________ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com |
From: Jose G. G. <jgo...@op...> - 2004-11-29 13:32:41
|
Konstantin Priblouda wrote: >--- Jose Gonzalez Gomez <jgo...@op...> >wrote: > > >>Any >>way, there is no >>information in the web about status of the project, >>expected release >>dates, downloadable source or binary tarballs or >>anything like that... >> >> > >2.0 is released and is in codehaus repository. >JIRA / Sources are also there. Maven takes care about >downloading. > > Sorry about my ignorance, but I guess if Maven takes care of the download, it must be in some Maven repository. I've been searching the www.codehaus.org site for a Maven respository with no success and the respository at ibiblio. I also have tried to find information about XDoclet in the site, but apart from xdoclet.codehaus.org I haven't found anything else... so the only way I've found to access XDoclet2 is to download the code from the CVS repository... what am I missing? >Though yuo do not need much infotmation about xdoclet >itself, it's plugins which do the job >( http://www.sourceforge.net/projects/xdoclet-plugins/ >) > > I've found about them, I guess they are released at the same place than XDoclet. >>what is the status of the project? Do you recommend >>a migration to >>XDoclet2 in its current state? >> >> > >It depends on what you need. Hibernate plugin is in >pretty good shape. EJB stuff is kind of orphaned. > > I understand from your words that the core is pretty stable, and only lacks plugins in certain areas,am I right? Thanks a lot, best regards Jose |
From: Konstantin P. <kpr...@ya...> - 2004-11-29 13:48:39
|
--- Jose Gonzalez Gomez <jgo...@op...> wrote: > Konstantin Priblouda wrote: > > >--- Jose Gonzalez Gomez <jgo...@op...> > >wrote: > > > > > >>Any > >>way, there is no > >>information in the web about status of the > project, > >>expected release > >>dates, downloadable source or binary tarballs or > >>anything like that... > >> > >> > > > >2.0 is released and is in codehaus repository. > >JIRA / Sources are also there. Maven takes care > about > >downloading. > > > > > Sorry about my ignorance, but I guess if Maven > takes care of the > download, it must be in some Maven repository. I've > been searching the > www.codehaus.org site for a Maven respository with > no success and the > respository at ibiblio. Codehaus repository lives at dist.codehaus.org >I also have tried to find > information about > XDoclet in the site, but apart from > xdoclet.codehaus.org I haven't found > anything else... so the only way I've found to > access XDoclet2 is to > download the code from the CVS repository... what am > I missing? xdoclet.codehaus.org was recently reworked and put back online ( though xdoclet plugins links did not survive it, but you can get to them from souceforge project ): http://www.sourceforge.net/pojects/xdoclet-plugins ) > I've found about them, I guess they are released > at the same place > than XDoclet. Yep. Fresh snapshot jars are at dist.codehaus.org , and ibiblio hosts some outdated... > I understand from your words that the core is > pretty stable, and > only lacks plugins in certain areas,am I right? Yes. YOu may choose to checkout sources of xdoclet-plugins, and see how xdoclet / plugins are invoked. You can also steal dependency specification from there. ( you may have to disable plugin.xwork cmopilation though. it fails for me ) regards, ===== ----[ Konstantin Pribluda ( ko5tik ) ]---------------- ... Sucht gerade nach neuen Projekt oder Festanstelung.... Plugins for xdoclet-2 are released. check it out at: http://www.sourceforge.net/projects/xdoclet-plugins/ ----[ http://www.pribluda.de ]------------------------ __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo |
From: Jose G. G. <jgo...@op...> - 2004-11-29 15:01:29
|
Konstantin Priblouda wrote: >--- Jose Gonzalez Gomez <jgo...@op...> >wrote: > > > >>Konstantin Priblouda wrote: >> >> >> >>>--- Jose Gonzalez Gomez <jgo...@op...> >>>wrote: >>> >>> >>> >> Sorry about my ignorance, but I guess if Maven >>takes care of the >>download, it must be in some Maven repository. I've >>been searching the >>www.codehaus.org site for a Maven respository with >>no success and the >>respository at ibiblio. >> >> > >Codehaus repository lives at dist.codehaus.org > > A final question... is there any way to get a source tarball of a given xdoclet2 release without downloading it from the CVS repository? Thanks again, best regards Jose |
From: Konstantin P. <kpr...@ya...> - 2004-11-29 15:20:28
|
--- Jose Gonzalez Gomez <jgo...@op...> > A final question... is there any way to get a > source tarball of a > given xdoclet2 release without downloading it from > the CVS repository? At the moment no. I think you do not grok it fully. You will not need sources of xdoclet itself - it's really small project based on generama ( generama.codehaus.org ) which just hosts plugins - xdoclet-plugins is that what you will really need. regards, ===== ----[ Konstantin Pribluda ( ko5tik ) ]---------------- ... Sucht gerade nach neuen Projekt oder Festanstelung.... Plugins for xdoclet-2 are released. check it out at: http://www.sourceforge.net/projects/xdoclet-plugins/ ----[ http://www.pribluda.de ]------------------------ __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail |
From: Jose G. G. <jgo...@op...> - 2004-11-29 15:43:52
|
Konstantin Priblouda wrote: >--- Jose Gonzalez Gomez <jgo...@op...> > > >> A final question... is there any way to get a >>source tarball of a >>given xdoclet2 release without downloading it from >>the CVS repository? >> >> > >At the moment no. I think you do not grok it fully. >You will not need sources of xdoclet itself - it's >really small project based on generama ( >generama.codehaus.org ) >which just hosts plugins - xdoclet-plugins is that >what you will really need. > >regards, > > Well, I'm currently using Gentoo Linux and I was thinking about the possibility of doing an ebuild (script used by portage to install packages). Currently they're trying to enforce installation of Java packages always compiled from source, and that's why I was searching for the sources. Unfortunately it seems it's becoming common for Java projects to release only compiled versions. Best regards Jose |
From: Konstantin P. <kpr...@ya...> - 2004-11-29 16:03:06
|
> Well, I'm currently using Gentoo Linux and I was > thinking about the > possibility of doing an ebuild (script used by > portage to install > packages). Currently they're trying to enforce > installation of Java > packages always compiled from source, and that's why > I was searching for > the sources. Unfortunately it seems it's becoming > common for Java > projects to release only compiled versions. What's wrong with jars placed in remote repository? regards, ===== ----[ Konstantin Pribluda ( ko5tik ) ]---------------- ... Sucht gerade nach neuen Projekt oder Festanstelung.... Plugins for xdoclet-2 are released. check it out at: http://www.sourceforge.net/projects/xdoclet-plugins/ ----[ http://www.pribluda.de ]------------------------ __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com |
From: Jose G. G. <jgo...@op...> - 2004-11-29 16:34:37
|
Konstantin Priblouda wrote: >> Well, I'm currently using Gentoo Linux and I was >>thinking about the >>possibility of doing an ebuild (script used by >>portage to install >>packages). Currently they're trying to enforce >>installation of Java >>packages always compiled from source, and that's why >>I was searching for >>the sources. Unfortunately it seems it's becoming >>common for Java >>projects to release only compiled versions. >> >> > >What's wrong with jars placed in remote repository? > > > Well, there's nothing wrong... I don't know if you know anything about Gentoo Linux, but in case you don't, it's a source based linux "metadistribution". They have a technology called portage that automatically downloads the source of the package you want to install, activates the optional features you have specified and compiles it optimizing it for your architecture (processor, compiler optimizations,...). They are trying to do the same with Java packages. I know this may be considered unneeded because of the bytecode, but they provide a few reasons you may find more or less interesting here (personally I think some of them are quite interesting): http://gentoo-wiki.com/Why_Build_Java_Code_From_Source So they're trying to provide an installation for Maven that compiles the package from source, and provide some means to be able to install locally any dependency needed in any Maven project, using the native installation tool, emerge/portage. Best regards Jose |
From: Konstantin P. <kpr...@ya...> - 2004-11-29 17:10:26
|
--- Jose Gonzalez Gomez <jgo...@op...> > > > Well, there's nothing wrong... I don't know if > you know anything > about Gentoo Linux, but in case you don't, it's a > source based linux > "metadistribution". They have a technology called > portage that > automatically downloads the source of the package > you want to install, > activates the optional features you have specified > and compiles it > optimizing it for your architecture (processor, > compiler > optimizations,...). They are trying to do the same > with Java packages. I > know this may be considered unneeded because of the > bytecode, but they > provide a few reasons you may find more or less > interesting here > (personally I think some of them are quite > interesting): > > > http://gentoo-wiki.com/Why_Build_Java_Code_From_Source well, reasons are valid. but there is a vast amount of dependencies - do they like to rebuikld everything? of course we can produce source distributions - just file issue in generama/xdoclet/xdoclet-plugins jira ( jira.codehaus.org ) so we do not forget it... regards, ===== ----[ Konstantin Pribluda ( ko5tik ) ]---------------- ... Sucht gerade nach neuen Projekt oder Festanstelung.... Plugins for xdoclet-2 are released. check it out at: http://www.sourceforge.net/projects/xdoclet-plugins/ ----[ http://www.pribluda.de ]------------------------ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Jose G. G. <jgo...@op...> - 2004-11-29 17:32:14
|
Konstantin Priblouda wrote: >--- Jose Gonzalez Gomez <jgo...@op...> > > >> Well, there's nothing wrong... I don't know if >>you know anything >>about Gentoo Linux, but in case you don't, it's a >>source based linux >>"metadistribution". They have a technology called >>portage that >>automatically downloads the source of the package >>you want to install, >>activates the optional features you have specified >>and compiles it >>optimizing it for your architecture (processor, >>compiler >>optimizations,...). They are trying to do the same >>with Java packages. I >>know this may be considered unneeded because of the >>bytecode, but they >>provide a few reasons you may find more or less >>interesting here >>(personally I think some of them are quite >>interesting): >> >> >> >> >> >http://gentoo-wiki.com/Why_Build_Java_Code_From_Source > >well, reasons are valid. but there is a vast amount of >dependencies - do they like to rebuikld everything? > > Well, the point here is that portage takes care of recursive dependencies, so the problem reduces to providing ebuilds for all packages and specifying dependencies among them. And you don't have to rebuild everything everytime. Let's say you have commons-logging and you have maven, xdoclet and tapestry that depends on it (I don't know if this is the case, just an example), you'll just compile commons-logging once, and then maven, xdoclet and tapestry will use the previously compiled and installed version of commons-logging. Of course the dependency specification is flexible enough to provide support for minimal/maximal versions, slotted versions (different versions of the same package installed simultaneously), blocking dependencies (packages that provide the same functionality and cannot be installed together), etc. And yes, they're trying to provide ebuilds from source for every package currently included in the distribution. There is also something going on in the area of creating an easily installable J2EE development platform including the whole stack... so Gentoo may become a quiet good Java development platform in the near future. >of course we can produce source distributions - just >file issue in generama/xdoclet/xdoclet-plugins jira >( jira.codehaus.org ) so we do not forget it... > > Will do so... thanks a lot for your time and sorry for the Gentoo "commercial" :o) Best regards Jose |
From: Brian T. <to...@co...> - 2004-11-29 20:28:24
|
Hello Jose, Yes, things are coming along rather nicely on this side of the fence. I've had no major problems with XDoclet for several months and decided that it was a good time to get things in shape so others could take advantage of it. Getting started with it is not hard at all, and you don't need the sources. The instructions that are provided at http://xdoclet.codehaus.org/Two+Minute+Introduction are a good introduction to the process and another resource I know of that you can cross-reference these instructions from is at http://cvs.dentaku.codehaus.org/viewrep/dentaku/dentaku/example-model/maven.xml?r=1.5. (Gentaku and XDoclet are similar, they just use a different MetadataProvider...) I'm not sure of any reason you would need the sources other than for creating your own plugins. If you want to do that, the hardest thing is grokking how PicoContainer works, and once you have that down, you are really in great shape. Really, all there is to it is for your class constructor to have parameters for the components it wishes to be injected with. So if you want a MetadataProvider, just put that in your constructor and it will magically appear. The typical problem is specifying a type for a parameter that returns no components (scoped too tightly) or too many components (scoped too loosely). For instance, a plugin usually wants a very specific form of generation (it's not an option for the container to randomly pick between FreeMarker or Velocity if your script is written for the other one that it chooses), but you do not want to choose a MetadataProvider too strictly because that way users cannot change it without recompiling your code. To illustrate, Gentaku changes the MetadataProvider to send in one that gets it's tag data from UML. If the plugin loosely specifies that all it cares is that the metadata that it requires is QDox Compatible (by using the interface instead of the class itself), the plugin will be compatible with both XDoclet2 and Gentaku. Anyway, the sources you probably will need are those of the plugins for example. I was going to send out a separate letter to this effect about XDoclet2, so here's the scraps of that: > We're attempting a restart on getting people using XDoclet2 and was > wondering if I might be able to find a small number of converts. The > reasons are compelling, and if you've thought about it, here's why" > > 1. Without question, the plugins are easier to write. It is > unnecessary to understand the entire inner architecture of XDoclet in > order to generate successfully, just duplicate a two files in an > existing project and you are rolling. > 2. The templating engine is no longer something that looks like XML > but acts completely different, it uses your choice of Velocity or > Freemarker for basic generation. If you've ever generated HTML with > either of these, you know that they are a breeze to work with, and > have active user communities behind them. > 3. If you are generating XML, such as with the XML descriptors for > J2EE applications, generating with Jelly allows you to be sure that > your templates are well-formed in any XML editor, saving many > headaches in comparison to generation with the original XDoclet. This > alone saves hours of hassle when generating XML. > 4. What's more, if you have developers on your team with existing > experience in any of these three templating technologies, they will be > immediately at home with the generation capabilities in XDoclet2. > > You may be asking yourself whether it's worth converting to XDoclet2 > and not just move over to annotations. I would say there are two main > reasons: > > 1. First, the number of plugins that are available for annotations are > small. While this will grow over time, so will the plugins available > for XDoclet. > 2. More importantly, the choices for your source of metadata in J5 > Annotations are limited to the source in your Java code. If you are > at all interested in generating from sources such as UML, you are > stuck. Same is true if you are not able to upgrade to J5 yet. Your other point about the state of the plugins is valid, but the case I try to make here is that writing plugins is so easy now that you'll probably find yourself writing them more than ever, and adding fixes to the existing ones will seem truly natural. Getting some new plugins and members contributing there would be a very good thing, so please consider it! We're always happy to help out. Please feel free to subscribe to the lists over at codehaus and get involved there. It's the best place for support on X2. They are listed at http://xdoclet.codehaus.org/Mailing+lists. Looking forward to seeing you around!! Brian Topping p.s. Don't forget about the logo contest (http://xdoclet.codehaus.org/Logo+Contest) winner to be announced Wednesday!! Jose Gonzalez Gomez wrote: > > Hi there, > > Recently I came across http://xdoclet.codehaus.org/ and found that > XDoclet2 seems to be in a rather usable state. Any way, there is no > information in the web about status of the project, expected release > dates, downloadable source or binary tarballs or anything like that... > what is the status of the project? Do you recommend a migration to > XDoclet2 in its current state? Is it possible to use with the current > release of Maven? > > Best regards > Jose > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > xdoclet-user mailing list > xdo...@li... > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > |