Comments inline
On 3/1/06, Jonathan Johnson <jonjohnson_at_mail.com> wrote:
> Malachi and Kohsuke,
>
> Malachi - Thanks for contributing to this discussion, your experience is
> needed! Yes, please do contribute to the code, its design and its user
> interface. Its currently not too complex because it relies on the XJC2Task.
>
> I looked at calling both Driver and XJC2Task.
>
> It appeared the XJC2Task had a simpler interface. Also, we are considering
> using the ant xjc configuration xml block. I was also concerned that Kohsuke
> had logic in there that was not in Driver that the Maven plugin would need
> as well. It appeared Driver was the common interface point for a plugin
> such as this and I have no problem using that instead. It would remove the
> ant dependency from the maven plugin which would be nice. I'm just
> concerned about loosing functionality and complicating the plugin code and
> ensuring future updates are not too painful.
>
>
The Driver interface is simply:
int retCode = Driver.main(String[] args, XjcListener)
where the String[] are the same command line options the user would use from
the command line directly with xjc.bat
the XjcListener I just sent to the AbstractMojo's getLog().xxx() methods
The only real concern I see with doing it separate is that they would be
maintained separately. Of course, with us writing code-writers, maybe we
could autogenerate both :)
> <plugin>
> <groupId>com.sun.tools.xjc.maven2 </groupId>
> <artifactId>maven-jaxb-plugin</artifactId>
> <executions>...</executions>
> <configuration>
> <xjc ant task definition here />
> </configuration>
> > ... instead of defining its own syntax for the maven plugin. I plan to
> > look at the code to see how hard it is to do this, and hopefully I
> > should be able to submit a patch for a consideration of Jonathan.
>
> The configuration instructions I sent in my announcement email are not
> written in stone. They are a starting point for us to decide on the best
> configuration interface. Using the ant xjc configuration is not out of the
> question and there are definite merits. Two technical roadblocks are 1)
> Maven does not make it obvious on how to get the raw configuration block.
> (Their documentation just talks about mapped configuration to the plugin
> java objects, but I'm sure there is a way) 2) XJC2Task does not have a
> method to submit the xml configuration section.
>
If we wanted to go that approach, we would probably just do it as an Ant
MOJO instead of a Java MOJO. I didn't do that on mine because I am much more
comfortable manipulating the File and URL objects in Java :) Ant MOJO docs
can be found at
http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html as
opposed to the Java MOJO docs at
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
>
> > I think that idea works well for those of us who have used Ant in the
> past...
> > but for users that are new to Maven2, they are likely not to learn Ant
> syntax
> > at all. I know my current build doesn't use any Ant syntax at all. We
> should try to
> > keep those users in mind.
> >> Those people still have to learn some syntax, so as long as we
> position
> >> the documentation correctly, I don't think it's any harder for any of
> our users.
>
> You guys know the configuration better than me. If its not more complex
> that what is on http://java.sun.com/webservices/docs/1.6/jaxb/ant.html then
> why not use the ant syntax. I used this document to create the current
> configuration settings. Are the current settings significantly different
> than the ant ones? Did I miss any features? Kohsuke did have a good
> point that if the configuration block was just passed through to XJC2Task
> then future features would be automatically added. I'm flexible.
>
>
Honestly, I think this could go either way. Personally, the two primary
reasons I moved to Maven was to use the reactor and quit using ant syntax
(since it was almost always boilerplate)... Right now, I have the reactor
building 9 submodules. My entire XJC configuration (in the top-level
pom.xmlonly) is:
<plugin>
<groupId>org.eoti.mojo</groupId>
<artifactId>eoti-tools-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>xjc</goal>
</goals>
</execution>
</executions>
<configuration>
<verbose>true</verbose>
<extensions>false</extensions>
<jaxbDebug>false</jaxbDebug>
<debugClassLoader>false</debugClassLoader>
<saveClasspath>true</saveClasspath>
<xlocator>false</xlocator>
</configuration>
</plugin>
but keep in mind that mine was my first mojo (a quick hack) and lots of
debug properties...
looking closer, the only thing that is really different from the Ant example
above is the <configuration /> tag.
> > Do you have access to the www/ portion of the JAXB project? If you need
> it to host your documentation, let me know.
>
> Yes if you would like me to contribute to the www documentation for this
> go ahead and set me up.
>
> > Do people need to specify jaxb-xjc as the dependency? I thought only the
> plugin depends on jaxb-xjc and not user app.
> This is why I don't quit my day job. You are correct the only the plugin
> depends on jaxb-xjc. I will reflect this in the documentation.
>
if the plugin specifies all 3 as dependencies, and the user's build lists
the plugin as a dependency (because they are generating sources, right?),
then it should auto-find all 3 jaxb dependencies when the tool is used.
>
> > Also, I wonder if it's possible for us to define an m2 repository on
> java.net so that jaxb-impl can specify a transitive dependency to jaxb api
> and etc.
>
> That would be nice to put things here
> https://maven-repository.dev.java.net/nonav/repository/. Reducing the
> amount of required dependencies is important. I believe all that has to be
> done is adding these to the poms on the repository. I noticed the poms are
> not in the java.net repository. I also noticed that the instructions on
> https://maven-repository.dev.java.net/ are for maven 1, not maven 2.
> Perhaps there is some java.net maven 2 prerequisite work to fulfill this
> transitive dependency goal.
>
The directory layout is different... I tried using the
maven-repository.dev.java.net with the legacy repository setting, but it was
constantly failing... I copied the jars locally and added the
maven-metadata.xml and the jaxb-WHICHJAR-WHICHVERSION.pom
so, my local repository, the path is something like:
<dir>\repository\maven2\jaxb\jaxb-impl\20051223\jaxb-impl-20051223.jar
as a side note, I had to take the "1.0/" subdirectory out of the xjc jar in
order to get IntelliJ to quit finding the wrong versions of classes....
maven was OK, but the editor was not.
> > Also, we should think about how to upload your plugin to the maven
> repository.
>
> Once we get a stable version with concise instructions lets publish it
> there too.
>
>
Should we be taking this discussion off the list?
Malachi