Hi Jeff, Thanks for the Maven link - I agree, let's use those conventions. You're quite right about the base java directory. I was looking at my sanbox structure, not the SVN tree - sorry. You can keep the base java directory if you like. I don't mind either way.
I got the idea of the 'modules' directory from other projects and was thinking of the API and the 2 implementations (DOM and OM) as separate modules, however they are not quite the same sort of 'modules'. So, we can drop my modules suggestion and just stick with woden/trunk/java/woden-api/..... or woden/trunk/woden-api/..... Will it help with SVN diffs against previous versions of files if we keep the base java directory (e.g. woden/trunk/java/woden-api/.....)? I agree on o.a.w.internal. We can separate on the OMxxx and DOMxxx classes into o.a.w.internal.om and o.a.w.internal.dom. I think the woden-api directory should just contain the java interfaces and the small number of API classes like WSDLFactory, but not the common implementation classes like BaseWSDLFactory and BaseWSDLReader which are currently in the 'internal' packages. Those are just refactored source from the implementation, not part of the API. We want to keep the API self contained, so that others can easily separate the API to provide their own implementation of Woden if they want to. I think there are some recent posts (earlier today) from Lawrence and Sagara about adding another directory for common implementation code (but still only building the 3 jars - woden-api, woden-dom-impl and woden-om-impl .... so just rolling the common impl classes into the dom-impl and om-impl jars). regards, John. On Tue, Jun 24, 2008 at 10:48 PM, Jeff MAURY <[EMAIL PROTECTED]> wrote: > > > On Tue, Jun 24, 2008 at 3:00 PM, John Kaputin (gmail) <[EMAIL PROTECTED]> > wrote: > >> 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. >> > In my initial proposition, I kept the base java directory because it > already exists but I agree with can skip it. > >> >> >> 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> > > I don't think the modules directory is needed. It adds a useless layer in > the hierachy. > >> >> >> How about changing .../resources/main/java to simply .../resources >> (similar to the existing Woden and Axis2 convention)? > > This should be src/main/resources as it is the Maven convention ( > http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html > ) > >> >> >> 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. > > I is defined in org.apache.woden.internal where I think it should be in > org.apache.woden.internal.dom > >> >> >> 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. > > My intent was to make them part of the woden-api module. > >> >> >> 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. > > Yes, I understand it. > > To summarize, please find the proposed layout: > > woden/trunk: > pom.xml > build.xml > build.properties > woden/trunk/woden-api: > src/main/java: Woden API and base classes > src/main/resources: schemas, ... > woden/trunk/woden-om: > src/main/java: OM Woden implementation > src/main/resources: OM specific resources (if any) > src/test/java: OM tests > src/test/resources: OM tests resources (if any) > woden/trunk/woden-dom: > src/main/java: DOM Woden implementation > src/main/resources: DOM specific resources (if any) > src/test/java: DOM tests > src/test/resources: DOM tests resources (if any) > woden/trunk/woden-ant: > src/main/java: ANT Woden task > src/main/resources: ANT Woden task resources (if any) > woden/trunk/woden-tool: > src/main/java: Converter sources > src/main/resources: WSDL Viewer > src/test/java: Converter tests > src/test/resources: Converter resources (not yet) > > Let me know if you have some remarks. > > Jeff > >> >> >> 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 >>> >> >> > > > -- > 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 >
