Re: iBATIS 3 Maven Project Layout Discussion
Great Summary Brandon. Given that Maven allows one to specify the resources folder (and even filter out certain files, like we will for .java files eventually), and considering that it does not cast a warning or error upon setting the resource directory to the source directory, I would consider it a feature supported by Maven. If we do encounter issues, I won't be shy about filing a bug report with either Maven or any plug-ins that have a problem with this configuration. iBATIS is not the only project to use this sort of setup. Hibernate also has classpath resources that sit directly beside the class files. While some may choose to separate them out for a very good reason, I believe most keep them in the exact same directory structure. So I would bet that this is quite a common practice. Cheers, Clinton On Fri, Aug 8, 2008 at 8:35 AM, Brandon Goodin [EMAIL PROTECTED]wrote: Hey All, There was a private discussion regarding the project layout and maven default conventions. I wanted to put the discussion out in front of everyone else, purely to get feedback and thoughts. At the moment the src directory contains source *and* resources. Maven has been configured to recognize the src/main/java as the resources and java directory. The reason for this is that it can get tedious to move between the java and resources directory rather than just edit a resource in the same package as the java class. The approach of using the java directory as a dual purpose directory is a departure from Maven's default directory structure. The concern of departing from that structure is that it may cause additional difficulties as we make heavier use of maven for coverage and reporting. If we experience difficulties in the future with Maven (because we all know it can be temperamental) it may be that we start having to separate all the resource files out of the java directory in order to eliminate it as a cause. So in summary... Current reasons for dual purpose java directory: * iBATIS 3 will make use of convention configuration and the visual proximity of resources to java is more visually correct * All around less directory clutter Concerns and counterpoints to making the java directory dual purpose: * Most IDEs can merge the resource and java directories in a package view. * We run the risk of avoiding potential maven headaches with plugins that don't handle the combined java/resources approach. In the end the question would be... Is it better to have coding convenience or follow the maven default approach of separating java and resource? Any experiences and comments are welcome. Brandon
POM Changes
I made the following changes to the pom.xml. I had to use 1.0.1B of JTA because it was available on the Sun repo. Hopefully that won't cause an issue. - set exclude on *.java in resource definitions for core and compat - added java.net repository definition and set jta to 1.0.1B. Not the latest but it compiles and passes all tests - added sources plugin to core and compat so that they now produce sources jars during the verify phase. B
Re: iBATIS 3 Maven Project Layout Discussion
That's good to hear. I'm too lazy to go confirm much of this :). So, thanks for doing some foot work to find examples where this is being used without problem. I know Maven provides for this feature. But, I have run across other features that were provided for and wound up causing headaches. Anyway, this is all good feedback. B On Fri, Aug 8, 2008 at 10:14 AM, Clinton Begin [EMAIL PROTECTED] wrote: Great Summary Brandon. Given that Maven allows one to specify the resources folder (and even filter out certain files, like we will for .java files eventually), and considering that it does not cast a warning or error upon setting the resource directory to the source directory, I would consider it a feature supported by Maven. If we do encounter issues, I won't be shy about filing a bug report with either Maven or any plug-ins that have a problem with this configuration. iBATIS is not the only project to use this sort of setup. Hibernate also has classpath resources that sit directly beside the class files. While some may choose to separate them out for a very good reason, I believe most keep them in the exact same directory structure. So I would bet that this is quite a common practice. Cheers, Clinton On Fri, Aug 8, 2008 at 8:35 AM, Brandon Goodin [EMAIL PROTECTED] wrote: Hey All, There was a private discussion regarding the project layout and maven default conventions. I wanted to put the discussion out in front of everyone else, purely to get feedback and thoughts. At the moment the src directory contains source *and* resources. Maven has been configured to recognize the src/main/java as the resources and java directory. The reason for this is that it can get tedious to move between the java and resources directory rather than just edit a resource in the same package as the java class. The approach of using the java directory as a dual purpose directory is a departure from Maven's default directory structure. The concern of departing from that structure is that it may cause additional difficulties as we make heavier use of maven for coverage and reporting. If we experience difficulties in the future with Maven (because we all know it can be temperamental) it may be that we start having to separate all the resource files out of the java directory in order to eliminate it as a cause. So in summary... Current reasons for dual purpose java directory: * iBATIS 3 will make use of convention configuration and the visual proximity of resources to java is more visually correct * All around less directory clutter Concerns and counterpoints to making the java directory dual purpose: * Most IDEs can merge the resource and java directories in a package view. * We run the risk of avoiding potential maven headaches with plugins that don't handle the combined java/resources approach. In the end the question would be... Is it better to have coding convenience or follow the maven default approach of separating java and resource? Any experiences and comments are welcome. Brandon
Re: POM Changes
Yeah the nice thing about it now is that nobody has to manually download a sun jar. I'm glad this will work. B On Fri, Aug 8, 2008 at 10:28 AM, Clinton Begin [EMAIL PROTECTED] wrote: I wonder what is up with JTA? The pom in the maven.org repo also only references 1.01b and the Sun distro of 1.1.1 isn't even properly packaged, almost as if it were just a PoC or something... I'm happy to use 1.0.1b... both seem to compile and at the end of the day they're just a bunch of interfaces. Cheers, Clinton On Fri, Aug 8, 2008 at 9:21 AM, Brandon Goodin [EMAIL PROTECTED] wrote: I made the following changes to the pom.xml. I had to use 1.0.1B of JTA because it was available on the Sun repo. Hopefully that won't cause an issue. - set exclude on *.java in resource definitions for core and compat - added java.net repository definition and set jta to 1.0.1B. Not the latest but it compiles and passes all tests - added sources plugin to core and compat so that they now produce sources jars during the verify phase. B
Re: iBATIS 3 Maven Project Layout Discussion
Hi, although it is possible to do this with maven I would rather like to see that the maven defaults are used - just because they are some kind of convention - and convention over configuration is one of the key features of maven. Anyway - I guess it is not a big deal to reuse the source folder for resources, so do it if feel you need it ;-) cheers Kai --- Original Nachricht --- Absender: Brandon Goodin Datum: 08.08.2008 16:35 Hey All, There was a private discussion regarding the project layout and maven default conventions. I wanted to put the discussion out in front of everyone else, purely to get feedback and thoughts. At the moment the src directory contains source *and* resources. Maven has been configured to recognize the src/main/java as the resources and java directory. The reason for this is that it can get tedious to move between the java and resources directory rather than just edit a resource in the same package as the java class. The approach of using the java directory as a dual purpose directory is a departure from Maven's default directory structure. The concern of departing from that structure is that it may cause additional difficulties as we make heavier use of maven for coverage and reporting. If we experience difficulties in the future with Maven (because we all know it can be temperamental) it may be that we start having to separate all the resource files out of the java directory in order to eliminate it as a cause. So in summary... Current reasons for dual purpose java directory: * iBATIS 3 will make use of convention configuration and the visual proximity of resources to java is more visually correct * All around less directory clutter Concerns and counterpoints to making the java directory dual purpose: * Most IDEs can merge the resource and java directories in a package view. * We run the risk of avoiding potential maven headaches with plugins that don't handle the combined java/resources approach. In the end the question would be... Is it better to have coding convenience or follow the maven default approach of separating java and resource? Any experiences and comments are welcome. Brandon
Re: iBATIS 3 Maven Project Layout Discussion
Everybody would always prefer to use the defaults. But it's important to know when not to. To clarify, for the purposes of the ibatis 3 source code, this only impacts the unit tests. When it comes time to include XML schemas (or DTDs), we'll likley put them in a separate resources folder. What I think it impacts more is you as an ibatis or hibernate developer... given a classpath like: src com domain yourapp module persistence PersonMapper.java PersonMapper.xml Would you for the sake of maven recreate that structure into source and resource directories? src com domain yourapp module persistence PersonMapper.java resource com domain yourapp module persistence PersonMapper.xml If so, why? What is the benefit to you? And has anyone ever asked why this is the default? And given any answer, is it good and/or universally applicable? Cheers, Clinton On Fri, Aug 8, 2008 at 9:24 AM, Kai Grabfelder [EMAIL PROTECTED] wrote: Hi, although it is possible to do this with maven I would rather like to see that the maven defaults are used - just because they are some kind of convention - and convention over configuration is one of the key features of maven. Anyway - I guess it is not a big deal to reuse the source folder for resources, so do it if feel you need it ;-) cheers Kai --- Original Nachricht --- Absender: Brandon Goodin Datum: 08.08.2008 16:35 Hey All, There was a private discussion regarding the project layout and maven default conventions. I wanted to put the discussion out in front of everyone else, purely to get feedback and thoughts. At the moment the src directory contains source *and* resources. Maven has been configured to recognize the src/main/java as the resources and java directory. The reason for this is that it can get tedious to move between the java and resources directory rather than just edit a resource in the same package as the java class. The approach of using the java directory as a dual purpose directory is a departure from Maven's default directory structure. The concern of departing from that structure is that it may cause additional difficulties as we make heavier use of maven for coverage and reporting. If we experience difficulties in the future with Maven (because we all know it can be temperamental) it may be that we start having to separate all the resource files out of the java directory in order to eliminate it as a cause. So in summary... Current reasons for dual purpose java directory: * iBATIS 3 will make use of convention configuration and the visual proximity of resources to java is more visually correct * All around less directory clutter Concerns and counterpoints to making the java directory dual purpose: * Most IDEs can merge the resource and java directories in a package view. * We run the risk of avoiding potential maven headaches with plugins that don't handle the combined java/resources approach. In the end the question would be... Is it better to have coding convenience or follow the maven default approach of separating java and resource? Any experiences and comments are welcome. Brandon
Re: SVN Directory Structure Cleanup
And by abator, I mean ibator :-) On Fri, Aug 8, 2008 at 4:09 PM, Clinton Begin [EMAIL PROTECTED]wrote: Hi all, I've moved the iBATIS SVN directory structure around. The structure is now: https://svn.apache.org/repos/asf/ibatis/trunk/java/ ibatis-2 ibatis-2-core ibatis-2-docs jpetstore-5 ibatis-3 ibatis-3-core ibatis-3-compat tools abator I'll email Jeff to see when it's safe to move abator under the ibatis-2 parent folder, as it would be nice to keep all of the compatible software together. I'm naming the ibatis modules somewhat redundantly (prefixed with ibatis-X...) only because it's nice to be able to check out from subversion without having to specify a meaningful directory name. And at least at this level it's nice to know which core or docs folder you're looking at in a single glance. If you have a working copy checked out, you can use a relocate to reconnect with the repository, but I usually prefer just to delete it and check it out again. NOTE: For the ibatis-3 devs, this did NOT change the iBATIS-3 directory structure at all, only V2.. Cheers, Clinton
Re: SVN Directory Structure Cleanup
Cool. That makes sense. On Fri, Aug 8, 2008 at 4:34 PM, Jeff Butler [EMAIL PROTECTED] wrote: I'd prefer to leave ibator where it is. As far as I can tell at this point, ibator support for ibatis3 will simply be a different plugin to the base code. So there won't be an ibator2 and an ibator3 - there will only be configuration options that specify the target runtime environment. In fact, even now ibator has no dependancies on ibatis at all - ibatis only comes into play with the ibator tests. Jeff Butler On Fri, Aug 8, 2008 at 5:09 PM, Clinton Begin [EMAIL PROTECTED]wrote: Hi all, I've moved the iBATIS SVN directory structure around. The structure is now: https://svn.apache.org/repos/asf/ibatis/trunk/java/ ibatis-2 ibatis-2-core ibatis-2-docs jpetstore-5 ibatis-3 ibatis-3-core ibatis-3-compat tools abator I'll email Jeff to see when it's safe to move abator under the ibatis-2 parent folder, as it would be nice to keep all of the compatible software together. I'm naming the ibatis modules somewhat redundantly (prefixed with ibatis-X...) only because it's nice to be able to check out from subversion without having to specify a meaningful directory name. And at least at this level it's nice to know which core or docs folder you're looking at in a single glance. If you have a working copy checked out, you can use a relocate to reconnect with the repository, but I usually prefer just to delete it and check it out again. NOTE: For the ibatis-3 devs, this did NOT change the iBATIS-3 directory structure at all, only V2.. Cheers, Clinton
