How about woden-impl-common rather that woden-impl-core? The code here really just common across Woden. It's not like the kernel or central component of Woden. Some of it is refactored base classes, some is common utility classes and the rest is WSDL or XML functionality that is not DOM or OM specific.
Some of the code in the DOM and OM packages is also part of the 'core' woden framework (like DOMWSDLReader and OMWSDLReader), so it might be confusing if we label the common code as 'core'. regards, John. On Tue, Jun 24, 2008 at 10:41 PM, Lawrence Mandel <[EMAIL PROTECTED]> wrote: > 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] > >
