Hi Jeff, You could make the changes and post patches. We would need a new JIRA to record the issue and capture your patches. That was how we handled changes which introduced the existing 3 module build last year. That was done by a summer intern student (non-committer). If you'd like to take this on, I'd be willing to review your changes and do the committing.
I'm not sure about a using 'java' twice in the directory structure you are proposing. For example: woden/java/woden-api/src/main/java Axis2 uses a structure like this: axis2/trunk/java/modules/<modulename>/src/<package> axis2/trunk/java/modules/<modulename>/test/<package> axis2/trunk/c/.... ...where /java distinguishes the java product from the c product. WS Commons uses: commons/trunk/modules/axiom/modules/axiom-api/src/main/java/<package> commons/trunk/modules/axiom/modules/axiom-api/src/test/java/<package> commons/trunk/modules/XmlSchema/src/main/java/<package> commons/trunk/modules/XmlSchema/src/test/java/<package> ...where there are only java products as indicated by the use of /java below /modules. I think we only envisaged a java product, so how about we adopt something similar to WS commons, like: woden/modules/woden-api/src/main/java/<package> woden/modules/woden-api/src/test/java/<package> How about changing .../resources/main/java to simply .../resources (similar to the existing Woden and Axis2 convention)? The org.apache.woden package contains just some high level Woden API interfaces and classes. It does not contain OM or DOM implementation classes. The WSDLFactory class does specify DOMWSDLFactory as a hardcoded default factory implementation, but the DOMWSDLFactory class is defined in a separate DOM package. One problem still exists. Some of the internal classes are not OM or DOM specific. For example, the BaseXXXXXXX classes refactor common behaviour into a super class which some of the DOMXXXX and OMXXXX classes extend. We need to consider where to put them in this module structure. One more very important consideration. We still have the original ANT build and we want to preserve it. That was a criteria when we introduced the Maven build. Any change to the project directory structure must not break the ANT build, so that will need to be changed too. regards, John. On Mon, Jun 23, 2008 at 11:22 PM, Jeff MAURY <[EMAIL PROTECTED]> wrote: > > > On Mon, Jun 23, 2008 at 4:17 PM, John Kaputin (gmail) <[EMAIL PROTECTED]> > wrote: > > > > Hi Jeff, > > last year when the ANT and Maven build was changed to separate the API > and the DOM and OM implementations, there was some talk about building the > WSDL 2.0 tools into a separate tools module. At that time the only tool was > the converter, but the WSDL 2 printer has since been added. This could be a > good thing. Currently the converter is built into the DOM implementation > jar. It should probably be in a separate jar. > > > > Are you proposing to refactor the src/ directory into some other > maven-like module structure that matches the modules created by the build? > Can you post a quick proposal. > > John, > > you are right. The layout I propose is a layout inspired by Maven > conventions. Please find a short description of what I propose: > > woden/java/pom.xml: main woden pom declaring modules woden-api, woden-om, > woden-dom and woden-tool > woden/java/woden-api: directory for the Woden API under which we find > src/main/java: sources for packages org.apache.woden, > org.apache.woden.internal except tool, om, dom, ant > resources/main/java: resources (schemas, ...) > woden/java/woden-om: directory for the Woden OM Impl under which we find > src/main/java: all OM specific sources (org.apache.woden.internal.om). By > the way, I suggest that all OM related classes should be in the > org.apache.woden.internal.om whereas now some of them are under > org.apache.woden. > src/test/java: sources for the OM tests > src/test/resources: resources for the OM tests (WSDL, ...) > resources/main/java: resources (schemas, ...) > woden/java/woden-dom: directory for the Woden DOM Impl under which we find > src/main/java: all DOM specific sources (org.apache.woden.internal.dom). By > the way, I suggest that all DOM related classes should be in the > org.apache.woden.internal.dom whereas now some of them are under > org.apache.woden. > src/test/java: sources for the DOM tests > src/test/resources: resources for the DOM tests (WSDL, ...) > resources/main/java: resources (schemas, ...) > woden/java/woden-tool: directory for the Woden Tool under which we find > src/main/java: Sources for the Converter. > src/test/java: sources for the converter tests > src/test/resources: resources for the converter tests (source WSDLs, > expected WSDL) > resources/main/java: resources (schemas, ...) > woden/java/woden-ant: directory for the Woden Ant task under which we find > src/main/java: Sources for the Ant task. > I don't see the use of the eclipseplugin folder, maybe by the felix plugin > ? > I don't know what to do with the wsdl-view because I can't guess how it is > used ? Maybe we need to put it into a separate module. > > The advantage of this layout is that we will keep the current JAR names > (even if the content will be slightly different), the dependency between the > POM will be removed (when I created a module for woden-tool, I need to > modify the other POMs in order to excludes all converter related stuff, and > the src and test directories will disappear. > Any comments ? > Jeff > > > > > > > > thanks, > > John. > > > > 2008/6/19 Jeff MAURY <[EMAIL PROTECTED]>: > >> > >> Hello, > >> > >> I have a simple question regarding the directory layout. > >> As I am working on the converter, I have created a small test framework > for the converter and added both classes and resources in the test > directory. > >> But it seems the converter is not yet compiled. > >> In order to test the converter, should I create a new tool or converter > module (like wooden-api, woden-om and wodem-dom). As there are lots of > dependencies between the modules, and the POMs are not really maven > compliant, shouldn't we start by refactoring the directory layout ? > >> > >> Thanks > >> Jeff > >> > >> > >> -- > >> La mélancolie c'est communiste > >> Tout le monde y a droit de temps en temps > >> La mélancolie n'est pas capitaliste > >> C'est même gratuit pour les perdants > >> La mélancolie c'est pacifiste > >> On ne lui rentre jamais dedans > >> La mélancolie oh tu sais ça existe > >> Elle se prend même avec des gants > >> La mélancolie c'est pour les syndicalistes > >> Il faut juste sa carte de permanent > >> > >> Miossec (2006) > >> > >> http://www.jeffmaury.com > >> http://riadiscuss.jeffmaury.com > >> http://www.lastfm.fr/listen/user/jeffmaury/personal > > > > -- > > La mélancolie c'est communiste > Tout le monde y a droit de temps en temps > La mélancolie n'est pas capitaliste > C'est même gratuit pour les perdants > La mélancolie c'est pacifiste > On ne lui rentre jamais dedans > La mélancolie oh tu sais ça existe > Elle se prend même avec des gants > La mélancolie c'est pour les syndicalistes > Il faut juste sa carte de permanent > > Miossec (2006) > > http://www.jeffmaury.com > http://riadiscuss.jeffmaury.com > http://www.lastfm.fr/listen/user/jeffmaury/personal >
