Re: [parabuild] BUILD for IBATIS (#53) on localhost TIMED OUT: Timed out after 120 minutes and was stopped.
Clinton, It is fixed now. http://parabuild.viewtier.com:8080/parabuild/index.htm?view=detailedbuildid=150 Thanks for letting us know! Slava
Re: iBATIS for Java 2.3.0 General Availability
In build management the generally accepted (or those to be considered OK) practices are: 1. Use adding a build number to product packages that are intermediate in nature, such as developer or nightly builds. The main advantage is that this allows quickly identifying the state of the code base at the moment of the build. Some also add a change list number if a version control system supports it. If the version control system doesn't support change lists, a version control time stamp may be used instead. There is no general best practice on the format, but most follow the scheme below.This naming scheme communicates well the temporarily/snapshot nature of the package.: product-name-major.minor.patch-build number-change-list-number The ultimate naming for iBATIS here would be ibatis-2.3.0-345-10685.jar 2. Use product-name-major.minor.patch for released product packages. This simplifies management of third-party dependencies for users, communication with support e.t.c For a product it also allows for easy branding. Usually, the build number and the change number are not required in the package names because these a values always documented through the release process. The ultimate naming for iBATIS here would be ibatis-2.3.1.jar In either case the build number and the change number are often included into the product packaging, release information on product web sites, release notes and About information. These are a couple of practices we, as a software build management company, recommend to our customers. They proved to work well over the years. Note that there is a case when using scheme number 1 is acceptable for released products when releases are small, often, with no intermediate releases, and a build system doesn't support automated management of a version number. The only example I can think of is Linux's package names. Just my two cents. Regards, Slava Imeshev [EMAIL PROTECTED] www.viewtier.com - Original Message - From: Paul Benedict [EMAIL PROTECTED] To: dev@ibatis.apache.org Sent: Saturday, February 17, 2007 2:47 PM Subject: Re: iBATIS for Java 2.3.0 General Availability Well thanks for listening at least. I suppose it is equal one way or another. Perhaps I will learn something from this :-) Clinton Begin wrote: I am not aware of any other project at Apache that includes a build number as part of their version number. So let's teach them something together. Clinton On 2/17/07, *Paul Benedict* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Clinton, I understand the argument, but I am not aware of any other project at Apache that includes a build number as part of their version number. That doesn't mean you're the only one, but I think it's a minority practice. And if it is a minority practice, there must be a good reason to not do it on a general basis. My point is the Build number is irrelevant to the release. If you produce snapshots until an official build, then you've eliminated the need for it. I never needed it, and I think eliminating it may ease releases. What you're essentially doing is using the build number as THE revision number. However, the revision doesn't need a promotion until you're ready to vote on a release. So given three releasable versions using your Build scheme (2.4.000, 2.4.256, 2.4.667), that's nothing really more than 2.4.0, 2.4.1, and 2.4.2. Paul Brandon Goodin wrote: I talked to larry and he floated his idea on this. My main thought about the build number was that it has to tie meaningfully back to the source state. Larry's idea does that perfectly... rawk. Thanks, Brandon On 2/17/07, *Brandon Goodin* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: This is very interesting and I'd like to know more about why this number is important apart from other things like a major.minor.revision.timestamp format. I'm not really picking up the importance from the previous comments. Here is my understanding, help me to clear the fog out... The serial is used to identify a unique build. This unique build is important for tracing back to what? If we do not have an anchor in our source code repository to compare it to what good does it do us? Brandon On 2/17/07, *Clinton Begin* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Paul, I disagree entirely. Open any product on your PC today, Java IDE, Visual Studio...anything. It will have
Re: [VOTE] Support for Maven (impacts Java version only)
I seriously doubt that this would require switching to Maven build. I cannot speak for a global catalog, but adding an item built with Ant to a local Maven repository is a one-liner. Regards, Slava Imeshev - Original Message - From: Jeff Butler [EMAIL PROTECTED] To: dev@ibatis.apache.org; [EMAIL PROTECTED] Sent: Wednesday, February 14, 2007 10:09 AM Subject: Re: [VOTE] Support for Maven (impacts Java version only) Yes - I should have asked that question with more subtlety. I guess the bottom line is that it is *possible* to get the jars to the repository without doing a maven build, but doing a maven build makes it much easier to publish to the repository. And our history shows that we are unlikely to get the jars to the repository with the build process we are using now. Right? Jeff On 2/14/07, Larry Meadors [EMAIL PROTECTED] wrote: IMO, that is like Can we clean a toilet with a toothbrush? Yes, we can, but who wants to offer up their toothbrush? Not me! :-) The question to me is: Can we get the iBATIS jars to the maven repository without doing a maven build, and is it the right way to do it? Yes we can, but no it's not. Larry On 2/14/07, Brandon Goodin [EMAIL PROTECTED] wrote: Can we get the iBATIS jars to the maven repository without doing a maven build? Yes On 2/14/07, Jeff Butler [EMAIL PROTECTED] wrote: In my own little perfect world, I'm -1. The iBATIS ant build is so simple now - I hate to see it mucked up just to supply the Maven meta-bs as Clinton so eloquently put it. However, I would like to see the iBATIS jars in the Maven repository - if for no other reason than to help those who can't figure out how to set a classpath without a tool. If a maven build makes that possible then I guess I'd be +2, but reluctantly. I think that supporting both Ant and Maven is problematical - seems like we should just pick one for simplicity going forward. So I guess I can't give a single vote. Can someone definitively answer this question: Can we get the iBATIS jars to the maven repository without doing a maven build? That's the key point for me. Jeff Butler On 2/14/07, Clinton Begin [EMAIL PROTECTED] wrote: Hi all, It strikes me that there was enough discussion around the Maven build to warrant an official vote for Maven support. +2 = Replace our Ant build entirely with a Maven build. +1 = Support Maven by including a Maven build alongside our Ant build. 0 = Don't care or I don't know enough about Maven to decide. -1 = Do not support maven. Cheers, Clinton
Re: Maven for Build?
My preference for a build to be self-contained and not to require to go out to run. Using Maven will prevent those having no Internet connection from building iBATIS. Regards, Slava Imeshev www.viewtier.com - Original Message - From: Brandon Goodin [EMAIL PROTECTED] To: dev@ibatis.apache.org Cc: [EMAIL PROTECTED] Sent: Tuesday, February 13, 2007 9:16 AM Subject: Re: Maven for Build? I can finish the pom that i have right now so that it mirrors the functionality of the current ant script. It won't hurt anything to have the pom in the repo. Brandon On 2/13/07, Jeff Butler [EMAIL PROTECTED] wrote: I'm open to maven for the iBATIS build. It would help a certain group of our users to get iBATIS into the Maven repository. Also - I don't think you have to generate the site with maven, we could just use it for the build. I've looked at it for Abator. Abator doesn't have much of a dependancy issue for the build (just needs a JRE and Ant), but the test phase is a different story. Abator testing is difficult because the tests are not so much an Abator itself, but on the code that Abator generates. So the build looks like this: 1. Build the JAR 2. Run a few tests (only three or four right now) 3. Build a test DB 4. Generate code against the DB 5. Compile the generated code and also a set of tests against the generated code 6. Run the tests on the generated code (several hundred) The Abater build also behaves differently if you're running wuth JSE 5 or not - there are more tests if you are using a Java 5 JDK. The build.xml for Abator is more complex than I'd like because of all this - so if Maven could help, then I'd be open to using for Abator too. Jeff Butler On 2/13/07, Larry Meadors [EMAIL PROTECTED] wrote: I like the idea - it makes the checkout faster, and mvn idea:idea is worth it's weight in gold, and our current build.xml is a bugger, I hate it. So, I wonder if we can skin the generated site to make it not look like crap^H^H^H^H every other maven generated site. :-) Larry On 2/12/07, Brandon Goodin [EMAIL PROTECTED] wrote: Hey Guys, I wanted to throw a bone out to everyone and ask the question Should we use Maven for our build?. I put together a POM today that makes use of the current iBATIS SQL Map structures. It is pretty darn simple and required very little effort. The largest amount of my time was spent refactoring the TestCL (Test Classloader) to use the current thread classloader as a parent due to some incompatibilities with how Maven runs it's test. That aside, I was surprised at how little effort it took to get the iBATIS SQLMap jar built. Plus, Because of the dependency management of Maven I was able to avoid having to use the oscache devsrc for oscache and avoid using the devlib jars. I only used Maven to build the Data Mapper/SQL Map. I wasn't familiar enough with Abator's build process to wire in Maven for it. Benefits: * I thought it would be good to aid in reducing the complexity of our current build/deploy. If we want to provide our jars to the Maven crowd we would be tasking the deploying member with taking the final jar built from ant and running deploy:deploy-file for it. I have to say that I looked through our release process and I really wouldn't want to add yet another step. Seems like maven can consolidate this for us. * We can run ant from within Maven if we so desire to continue performing tasks that maven doesn't provide for. Additional benefits, thoughts, or concerns? Thanks, Brandon
Re: Maven for Build?
- Original Message - From: Jeff Butler [EMAIL PROTECTED] To: dev@ibatis.apache.org Sent: Tuesday, February 13, 2007 9:28 AM Subject: Re: Maven for Build? +1 for Ant as the primary build. But could we get iBATIS into the Maven repository somehow so we could stop all the whining from Maven mavens? :-) Exactly. ant send-to-maven-repository Regards, Slava Imeshev
Re: Maven for Build?
RE: internet connectivity... If you don't have an internet connection then you are in a sad sad state and i'd like to know how you got ahold of ibatis in the first place. Not allowing people using iBATIS will slow its adoption. You may work in a strict security environment that prohibits certain connections. Fetching something from outside may be disastrous in such environments. RE: self contained build I believe that self contained build are overrated as well. As long as you have the jars (which maven will download for you). Then you are golden. Actually, no. Basic change management requires knowing what makes your product. Anyway, let me suggest that you guys let me write the pom and we'll see if all the unnecessary anger and hype is really worth the raise in blood pressure. Boredom shouldn't drive technology decisions, common sense should. In any case, Viewtier will continue running Continuous Integration for iBATIS. Just let me know if there are changes: http://parabuild.viewtier.com:8080/parabuild/index.htm?displaygroupid=7 Regards, Slava Imeshev www.viewtier.com
