Well, yes. I'm not sure you understand the basics of Maven. Maven does not work with files, it works with artifacts. It kind of is the same thing, but on an abstract level. So, a Maven project produces an artifact. OK? Sometimes that artifact is a jar, but it depends on the project and could be pretty much anything.
Maven is also built upon convention over configuration. In simple terms, everything is standardized. So, if you want to have a jar with Java classes that are generated from a schema (or what ever), (I strongly believe) you should construct that project the same way as if you were creating the Java classes yourself. With that I mean you should have a jar project using the standard lifecycle and bindings, the only difference is that the Java source is produced by a plugin. By doing so, everyone will quickly understand how that project works, without any knowledge of any specific plugin. Also, it will be very little differnce from a project generating Java classes through a jaxb plugin (or whatever). Using a plugin's unique fetures like generating a jar isn't a good idea (I think) as it is not standard and will force you to set up your project in a non-standard way. So, back to your question. The "first module" (the Maven project generating the Java classes through the xmlbeasn plugin) is build in the standard Maven way. That is, "mvn install" to get the artifact (an jar in this case) installed in your local repo. Or "mvn deploy" to get it deployed (distributed) to your remote repo (if you have one). I earlier suggested that you have a "top" (aggregating) project containing this project and all you other ones. So, do the build from that one and everything will just work. The artifacts will be generated (the plugin should handle optimization like deciding if it's necessary to re-generate the Java classes). It's not any different from if you were to write your own Java classes that other parts of your system use. Yes, standard is good. Someone else suggest ways where you provide command line stuff like groupId etc. I wouldn't go that path. It will make everything so hard. Do it the real Maven way and Maven will help you do things faster. If you haven't done so, I recommend that you read the free book Maven: The defitive Guide by SOnatype so that you get an understanding of the Maven basics. It will greatly help in the future. /Anders On Thu, Aug 27, 2009 at 02:47, youhaodeyi <[email protected]> wrote: > > How can I create the first module? Do you mean I run the command "mvn > install" on the configure.jar file? > If so, every time the xsd file changed, I have to install the cnofigure.jar > file manually. > > Nicolas Duminil wrote: > > > > You have to have a main pom having two modules: the first one installs > > your configure.jar as an artefact in your local repository. The second > one > > is the one you've showed, to which you add a dependency to the previous > > generated artefact. > > > > Nicolas > > > > -- > View this message in context: > http://www.nabble.com/maven-xmlbeans-problem-tp25149630p25164219.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
