The seam script (which we all call seam-gen) just got another upgrade tonight, this time focused on the build. Up to this point, the seam script has been a couple steps behind other project generation tools, such as Grails, because the user has been locked into having to run it from a Seam distribution directory. You may know from using Grails that their approach is to add grails to your PATH and set GRAILS_HOME and use it like a system command. I have an approach that falls somewhere in between and frankly is more intelligent. First and foremost, i have unlocked us from having to run the seam script from the Seam distribution directory. Now you can run it out of any directory on the computer and it will work as it does today (meaning your current working directory can be anywhere). Internally it figures out your current directory and the SEAM_HOME environment variable relative to the location of the script (there is really no reason to make the user set this environment variable, that is just a stupid requirement). More on the current working directory in a second. Btw, I also put in a check that the user has JAVA_HOME pointing to a JDK because otherwise the Ant build is going to fail anyway. As you may know, I have been moving build.properties into the project as the file seam-gen.properties since last spring (really since Seam 2.0). We just haven't done anything with it...until now. Here is the big enhancement. If your current working directory happens to be a directory that has a seam-gen.properties file AND and build.xml file, then the seam script recognizes that you are in a Seam project and operates using the seam-gen.properties file in that directory rather than the seam-gen/build.properties from the Seam distribution. If you put the seam script on your PATH, then you can simply enter a project and run "seam generate". If you are too lazy to put it on your PATH, then you have to run something like "~/projects/seam-trunk/seam generate". Either way, it will work. Btw, I also fixed the Windows batch script (which was really no fun at all. Windows sucks. It's like playing with those really big legos that you give 3 year olds). On top of that, the outputs after the generate command are aware of whether you are running the seam script outside a project or inside a project and thus tell you to use seam or ant respectively. For example, if you run "seam generate" from within a project, it will tell you to run "ant restart" (instead of "seam restart") after it is done its work (no need to keep having to go through the seam script). The next steps I guess are for JBossTools to use the seam-gen.properties inside the project (if it doesn't already). As far as JBossTools is concerned, it doesn't really care where the properties file is because it has the advantage of being aware of the workspace. Most of the upgrades here had to happen in the seam script. I am going to take this message and the previous one about the seam-gen upgrades and do a blog entry on in.relation.to in a day or so. Cheers, Dan -- Dan Allen Software consultant | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Thu, Oct 9, 2008 at 4:46 AM, Sanne Grinovero <sanne.grinovero(a)gmail.com&gt; wrote: > thanks Dan, I really like these changes. > IMHO next step should be to merge "seam setup" and "seam new-project" > to be more consistent, and save directly all settings to the project > specific workspace. > I never understood the name behind "setup": it looks like you are > going to setup Seam but it is > actually going to make project-specific questions; > It's nice they get saved there as default settings for next project, > but should be used only as such. The only problem I see with moving the build.properties file into the project (rather than copying it) and also making the user go through the setup questionnaire (rather than using two steps) is that people like me (and perhaps Jay) who are generating about 10 - 20 seam-gen projects a day enjoy the fact that I can run over and over again:

seam delete-project create-project generate restart Once I get the build.properties file in place, then I can just churn out the project. So if we combine setup and create-project, we would need to leave behind build.properties and then have a quiet switch that would suppress the questionnaire: seam -q delete-project create-project generate restart -Dan -- Dan Allen Software consultant | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

Do you mean that the SEAM_HOME is figured out and set based on your current directory? I think you are missing a "sets" in there :-) This seems like a really good way to support multiple projects with seam gen without having to figure out some verbose arguments for the script in distribution directory.

Can a user also use "seam restart"? Some users may be used to using the seam script.

The seam script (which we all call seam-gen) just got another upgrade tonight, this time focused on the build. Up to this point, the seam script has been a couple steps behind other project generation tools, such as Grails, because the user has been locked into having to run it from a Seam distribution directory. You may know from using Grails that their approach is to add grails to your PATH and set GRAILS_HOME and use it like a system command. I have an approach that falls somewhere in between and frankly is more intelligent. First and foremost, i have unlocked us from having to run the seam script from the Seam distribution directory. Now you can run it out of any directory on the computer and it will work as it does today (meaning your current working directory can be anywhere). Internally it figures out your current directory and the SEAM_HOME environment variable relative to the location of the script (there is really no reason to make the user set this environment variable, that is just a stupid requirement). More on the current working directory in a second. Btw, I also put in a check that the user has JAVA_HOME pointing to a JDK because otherwise the Ant build is going to fail anyway. As you may know, I have been moving build.properties into the project as the file seam-gen.properties since last spring (really since Seam 2.0). We just haven't done anything with it...until now. Here is the big enhancement. If your current working directory happens to be a directory that has a seam-gen.properties file AND and build.xml file, then the seam script recognizes that you are in a Seam project and operates using the seam-gen.properties file in that directory rather than the seam-gen/build.properties from the Seam distribution. If you put the seam script on your PATH, then you can simply enter a project and run "seam generate". If you are too lazy to put it on your PATH, then you have to run something like "~/projects/seam-trunk/seam generate". Either way, it will work. Btw, I also fixed the Windows batch script (which was really no fun at all. Windows sucks. It's like playing with those really big legos that you give 3 year olds). On top of that, the outputs after the generate command are aware of whether you are running the seam script outside a project or inside a project and thus tell you to use seam or ant respectively. For example, if you run "seam generate" from within a project, it will tell you to run "ant restart" (instead of "seam restart") after it is done its work (no need to keep having to go through the seam script). The next steps I guess are for JBossTools to use the seam-gen.properties inside the project (if it doesn't already). As far as JBossTools is concerned, it doesn't really care where the properties file is because it has the advantage of being aware of the workspace. Most of the upgrades here had to happen in the seam script. I am going to take this message and the previous one about the seam-gen upgrades and do a blog entry on in.relation.to in a day or so. Cheers, Dan

> The next steps I guess are for JBossTools to use the > seam-gen.properties inside the project (if it doesn't already). As far > as JBossTools is concerned, it doesn't really care where the > properties file is because it has the advantage of being aware of the > workspace. Most of the upgrades here had to happen in the seam script. We never could use seam-gen.properties because it was 1) not in the project 2) did not contain anything we could use... #1 has changed, but what is relevant for us in #2 ? /max