On Tuesday 16 Sep 2003 11:15, Lukasz Piestrzeniewicz wrote: > I'm new to both maven and XDoclet. When I encountered problems with > using both, instead of getting bad habits using current version of > maven-xdoclet-plugin I've tried to fix some things ;)
> Setting XDoclet dependencies was quite frustrating. Especially, that my > project doesn't depend on XDoclet. What IS depending on XDoclet is > XDoclet plugin. So all dependencies for plugin should be listed in > plugin's project.xml. This means, that all xdoclet-some-module.jar must > be listed, no matter which task will be called. This is the same problem > you mention. > > I think, that because different XDoclet tasks are parts of the same > plugin it just must stay this way. Single task may depend on only some > modules, but plugin just depends on all of them. What *should* happen is you have an "init" goal in the plugin (look at other plugins and see what I mean). This way the "init" goal could include xdoclet and xjavadoc, and the xdoclet module into the CLASSPATH. Then each individual goal in the plugin can add on their own particular dependencies (other than the xjavadoc, xdoclet, xdoclet module ones which have already been included in the "init"). It is simply separating things out so that you do not include things in the classpath that are unnecessary - leaving it so that all goals do the same is bad structure. > I'm not sure why XDoxlet dependicies are set in form: > > <id>xdoclet+some-module</id> > > Shouldn't it be set like this? > > <groupId>xdoclet</groupId> > <artifactId>xdoclet-some-module</artifactId> Both are equally valid, but the second one is the clearer definition and the one adopted more often now in Maven. The first is more like what was in Maven some time back. > I think that this dependencies should also be made available for Ant > classloader by using form: > > <dependency> > ... > <properties> > <classloader>root</classloader> > </properties> > </dependency> > > Then, the plugin.jelly doesn't need ANY classpath entries in taskdefs. You should include dependencies in the plugin.jelly goals appropriate to what that goal does, not just dump everything in the root classloader. > This produces one problem, the plugins project.xml must also list j2ee > dependency, since at least ejb-doclet depends on this. I'm not sure if > this is a good approach, maybe this can be changed somehow? If a plugin depends on j2ee then it must be included in the project.xml (otherwise you are enforcing that applications using the plugin include it themselves, which is wrong). > Note, that classpath entries were removed and plugin explicitely depends > on j2ee-1.4.jar. This plugin after compilation no longer requires any > XDoclet dependencies to be set in project descriptor. Do you have to have j2ee v1.4 ? ejbdoclet does not depend explicitly on that version - you could use 1.2 or 1.3, and 1.3 is much more common. The other thing is that this dependency should only be added to the classpath in the plugin.jelly in goals that need it. For example jdodoclet does not want anything to do with j2ee.jar so it shouldn't be included there > Also the jar file for xjavadoc must be now placed in repository under: > .maven/repository/xdoclet/jars/xjavadoc-1.0.1.jar (instead of old > location .maven/repository/xdoclet/jars/xdoclet-xjavadoc-1.0.1.jar). Agreed. That makes more sense than putting it as xdoclet-xjavadoc. -- Andy ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
