Hi Sagara, We discussed this issue on today's Woden call and came up with the same suggestion as you. I think a woden-core or woden-impl-core module is a good option. We also discussed not building a separate jar from this module and simply rolling the classes into either the dom or om jar, as is currently done.
Thoughts? Lawrence "Sagara Gunathunga" <[EMAIL PROTECTED]> 06/24/2008 09:40 AM Please respond to [email protected] To [email protected] cc Subject Re: Question about layout Hi guys , As John pointed in his mail we still have a one problem left to slove , we have several base classes those are common for both DOM and OM implementations , If I take a example we have separate two WSDLReader class for DOM and OM implementatios but there is a common BaseWSDLReader class that common for above two classes , where we put this class ..? one possible solution is to have four modules instead of three,as follows woden-api woden-core woden-impl-dom woden-impl-om this is just a suggestion for a discussion , I'm also think this structure is little bit complex. Thanks , Sagara Gunathunga Blog - ssagara.blogspot.com Web - http://sagaras.awardspace.com/ On Tue, Jun 24, 2008 at 6:44 PM, Saminda Abeyruwan <[EMAIL PROTECTED]> wrote: > Hi All, > > <root>/src/main/java > <root>/src/test/java > <root>/src/main/resources > <root>/src/test/resources > > is the default MVN layout. If prior approach is used, what you need to write > in pom.xmls will be minimum. > > If you guys thinking of Maven2 module as > woden-api > woden-impl-dom > woden-impl-om, > > IMHO, following package structure will really aid in creating a clean OSGi > Woden bundles, > woden-api -> org.apache.woden.api > woden-impl-dom -> org.apache.woden.impl.dom > woden-impl-om - >org.apache.woden.impl.om > > Since the prior change would break the backward compatibility in API, I > wouldn't suggest it at this moment. Prior structure would be consider as > nice to have. > > Thank you! > > Saminda > > On Tue, Jun 24, 2008 at 6:30 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. >> >> 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 > > > > -- > Saminda Abeyruwan > > Senior Software Engineer > WSO2 Inc. - www.wso2.org -- Sagara Gunathunga Blog - ssagara.blogspot.com Web - http://sagaras.awardspace.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
