Could someone do a bit of QA for me and check that the instructions at http://www.seamframework.org/Documentation/RunningWeldExamplesWithJBossAp... work for others than me? Thanks! _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Currently we use ant to deploy the examples to JBoss AS, not Maven (we could try to use the JBoss AS plugin for Maven, just never got around to it). So there aren't really any maven instructions to write about. On 7 Dec 2009, at 15:51, Steven Boscarine wrote: > Should there be instructions for Maven as well? > > > > Pete Muir wrote: > >> Could someone do a bit of QA for me and check that the instructions at http://www.seamframework.org/Documentation/RunningWeldExamplesWithJBossAp... work for others than me? >> >> Thanks! >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >>

On 7 Dec 2009, at 16:06, Steven Boscarine wrote: > If it helps, I started some for the archetypes at > http://www.seamframework.org/Documentation/GettingStartedWithCDIInJBossAS... This is kinda a bit different, my page is about using the examples, yours is about a user creating a new app. Once we have some releases of your stuff out, we should link the pages together :-)

> > If you see any opportunities for merging the docs, I can help out. I > think maven instructions will be helpful for maven users. > > > Can the ANT script use JBOSS_HOME so the user can start without editing > any properties files? It could do, it would be better to investigate the JBoss maven plugin IMO.

If it matters, I wasn't really suggesting changing the maven setup, just wondering if life would be easier for the ANT users if their script read JBOSS_HOME as it is the only value needed to run the examples in JBoss.

The obvious side effect would be that they could simply set an environment variable that was probably already set on their system and then run either the maven or the ant version without editing files.

There's a tiny benefit for those checking out the code from SVN. They won't get icons in Tortoise/Eclipse telling them they have uncommitted changes. I usually personally avoid setting machine-specific files in SCM if I can find an alternative as I hate it when I am the dummy who accidentally commits his local config.

I checked build.xml and you are correct. The script accommodates local.build.properties.

I can put in the JBOSS_HOME fix. I'll be my first time editing an ANT script in 5 years. ANT is my ex-wife. I'll be interesting to check up on her. :)

On Wed, Dec 9, 2009 at 2:39 PM, Steven Boscarine <steven.boscarine(a)childrens.harvard.edu&gt; wrote: > > I checked build.xml and you are correct.  The script accommodates > local.build.properties. In a way, local.build.properties is for Weld developers (using SVN) more than end users (who will likely just modify build.properties if need be). I would throw it in the documentation, saying that it is for developers who want to override w/o touching build.properties. But that really it is intended for the developers. > > I can put in the JBOSS_HOME fix.  I'll be my first time editing an ANT > script in 5 years.  ANT is my ex-wife.  I'll be interesting to check up on > her.   :) Ant is the type of ex-wife (or ex-husband) that always welcomes you home. Then you hate yourself for coming back.

-Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

> > >> >> If you see any opportunities for merging the docs, I can help > out. I >> think maven instructions will be helpful for maven users. >> >> >> Can the ANT script use JBOSS_HOME so the user can start without > editing >> any properties files? > > It could do, it would be better to investigate the JBoss maven > plugin IMO. > > > I know the JBoss deploy plugin quite well. It does use JBOSS_HOME by > default, but can be overridden in the Maven plugin configuration. But > the best solution is to assign the JBOSS_HOME to a Maven property and > then use that propery in the plugin configuration. Then, you can use > either JBOSS_HOME or the Maven property to tune the value. What I > don't think is possible (w/o some build magic) is to have Maven read > the value in build.properties (because that would just make life too > easy, say the Maven guys). > > -Dan If it matters, I wasn't really suggesting changing the maven setup, just wondering if life would be easier for the ANT users if their script read JBOSS_HOME as it is the only value needed to run the examples in JBoss. The obvious side effect would be that they could simply set an environment variable that was probably already set on their system and then run either the maven or the ant version without editing files. There's a tiny benefit for those checking out the code from SVN. They won't get icons in Tortoise/Eclipse telling them they have uncommitted changes. I usually personally avoid setting machine-specific files in SCM if I can find an alternative as I hate it when I am the dummy who accidentally commits his local config.

On 12/09/2009 06:18 AM, Pete Muir wrote: > > Right, we have local.build.properties for this. > > But this is a good change overall, if you want to change it, that would be > great :-) (affected are examples and TCK runs I think) > I made the change and left the local.build.properties reference, so no one will need to change their configs as long as they're not using the main build.properties file. Examples appear to work fine. The new build should work identically to the old one. How do I confirm this hasn't affected the TCK? Also, what do I have to do beyond confirm http://www.seamframework.org/Documentation/RunningWeldExamplesWithJBossAp... w/ JBOSS_HOME to test the change? Thanks, Steven

Steven, I see that you set jboss.home to ${env.JBOSS_HOME} in build.xml, but why not do this in build.properties? The reason I suggest that is because having the following in build.properties is just misleading and cruft (it's what has always been there, so I'm not implying you added it) jboss.home=/Applications/jboss-5.2.0.Beta1 tomcat.home=/Applications/apache-tomcat-6.0.20 Better is for build.xml to simply read build.properties as defined here: jboss.home=${env.JBOSS_HOME} tomcat.home=${env.CATALINA_HOME} Here are the lines you need in build.xml <property environment="env"/><!-- assign OS environment variables to an object visible to ANT --> <!-- preserve local build.properties if they're still being used --> <property file="${wbexamples.dir}/../jboss-as/local.build.properties" /> <property file="${wbexamples.dir}/local.build.properties" /> <property file="${wbexamples.dir}/../jboss-as/build.properties" /> <property file="${wbexamples.dir}/build.properties" /> They can either setup jboss.home in the jboss-as directory or the root of the examples directory. It first uses local.build.properties overrides (for developers that do have multiple instances of JBoss AS that don't coincide w/ JBOSS_HOME), then we check build.properties, which should be as above. -Dan On Wed, Dec 9, 2009 at 3:35 PM, Steven Boscarine <steven.boscarine(a)childrens.harvard.edu <mailto:steven.boscarine@childrens.harvard.edu>> wrote: On 12/09/2009 06:18 AM, Pete Muir wrote: Right, we have local.build.properties for this. But this is a good change overall, if you want to change it, that would be great :-) (affected are examples and TCK runs I think) I made the change and left the local.build.properties reference, so no one will need to change their configs as long as they're not using the main build.properties file. Examples appear to work fine. The new build should work identically to the old one. How do I confirm this hasn't affected the TCK? Also, what do I have to do beyond confirm http://www.seamframework.org/Documentation/RunningWeldExamplesWithJBossAp... works w/ JBOSS_HOME to test the change? Thanks, Steven -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

I think the point is that the build.properties file should just be defaulting to the system property, encouraging the user to control the value that way (no meddling required).

Fine with me. I never even plan on using the ANT script anyway...just trying to make it easier for you to document.

If it were me, I'd prefer a fail message telling me to set JBOSS_HOME and just handle everything with OS variables and not even have a properties file to edit.

I don't really have much of an opinion on the subject. I'll apply your suggestions and then maybe the ant strategy should be architected by an actual ANT user.

On 12/09/2009 06:18 AM, Pete Muir wrote: > > Right, we have local.build.properties for this. > > But this is a good change overall, if you want to change it, that would be great :-) (affected are examples and TCK runs I think) I made the change and left the local.build.properties reference, so no one will need to change their configs as long as they're not using the main build.properties file. Examples appear to work fine. The new build should work identically to the old one. How do I confirm this hasn't affected the TCK?