Re: [action1] cleaning up the build
On 4/20/06, Don Brown [EMAIL PROTECTED] wrote: Can we require these snapshot plugins in our POM somehow? I'm fine with working with snapshots, but their download and use should be automatic. When the Javadoc plugin gets fixed, yes. For now, the released versions are working (you just don't get the aggregated Javadoc.) I added a few things to the reporting section and published struts-core since it doesn't overwrite anything: http://struts.apache.org/struts-action/struts-core/ Still to do... * Add the dependencyManagement/site section to the rest of the poms. * Add the rest of the reporting plugins. (See one of the project.xml files for a list.) * Figure out how to set the location of the checkstyle config file relative to the parent pom. Unconfirmed, but I think it's looking for 'build/struts_checks.xml' under each module. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action1] cleaning up the build
Can we require these snapshot plugins in our POM somehow? I'm fine with working with snapshots, but their download and use should be automatic. Don Wendy Smoak wrote: On 4/18/06, Don Brown [EMAIL PROTECTED] wrote: We definitely need an action/src/site directory to contain the root site.xml that others inherit, and if you can get over the aforementioned issue, then collecting all docs there would work for me. I moved action/core/src/site up to src/site, and here's the aggregated Javadoc: http://cvs.apache.org/builds/struts/maven/test-site/struts-action/apidocs/ I'm working with snapshots of the site and javadoc plugins, so if any of the configuration causes a problem with the latest released versions, just comment it out or let me know. Thanks, -- Wendy - 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]
Re: [action1] cleaning up the build
On 4/14/06, Wendy Smoak [EMAIL PROTECTED] wrote: ... to get the Javadoc generated for the site, add this to action/pom.xml: reporting plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId configuration aggregatetrue/aggregate /configuration ... I built the javadoc plugin to try the aggregation feature, which partially works. It builds the aggregated Javadoc fine, but then fails afterwards. Brett is aware of it and http://jira.codehaus.org/browse/MJAVADOC-66 has been opened. Looking at the output, which I'll post an example of tonight, I think we need to re-package the app that's using the example package. (Cookbook?) It looks strange in the consolidated list of packages. Don/James... do you want to pull all the xdocs up from the sub-modules of Action and have them all in action/trunk/src/site/ ? I would imagine that eventually, all the reports (JUnit test results, etc.,) will be able to be aggregated and the sub-sites wouldn't be necessary. I'm not sure yet, but making Action's 'site' a module might work better: action/trunk/site/src/site. The WADI incubator project has a similar structure and might be worth looking at: http://svn.apache.org/repos/asf/incubator/wadi/trunk/ -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action1] cleaning up the build
On 4/18/06, Don Brown [EMAIL PROTECTED] wrote: We definitely need an action/src/site directory to contain the root site.xml that others inherit, and if you can get over the aforementioned issue, then collecting all docs there would work for me. I moved action/core/src/site up to src/site, and here's the aggregated Javadoc: http://cvs.apache.org/builds/struts/maven/test-site/struts-action/apidocs/ I'm working with snapshots of the site and javadoc plugins, so if any of the configuration causes a problem with the latest released versions, just comment it out or let me know. Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action1] cleaning up the build
I spent some time yesterday looking at what's left wrt the sample apps. From struts/action/ I can execute the following: $mvn (which runs the install target by default) Looks like all artifacts are built correctly, so I proceeded to deploy all of the web apps... struts-cookbook - was missing dependency on taglib - fixed - I went through all of the examples and they seem to run ok strutsel-exercise-taglib - href link from /logic-redirect.jsp redirects to port 9090 - fixed (changed to redirect to root of application) struts-mailreader - good to go (Does the web tests work for this yet?) struts-blank - looks good struts-examples - looks good struts-faces-example1 struts-faces-example2 - not working atm struts-scripting-mailreader - The way I brought this app up to 1.3.x, was to copy the latest mailreader and apply the changes manually. One caveat to note though is that session management is handled differently now in the mailreader app than it was with earlier versions. The BaseAction checks for a user bean in the session. I don't know how to do inheritence in groovy, so I'll punt on that for now. I also spent some time looking at the site docs. They all seemed to run ok, and although I had to run the top level separately from action1, they look fine. So, what's next? -- James Mitchell On Apr 6, 2006, at 4:31 PM, Don Brown wrote: Ok, I'm working with Wendy to do the Maven 2 conversion. Here is the plan we have decided on: 1. All the jar artifacts (core, taglib, el, faces, scripting, extras) get their own directory and pom 2. All the war artifacts, including the example apps from modules like faces and scripting, will be moved into the apps/ directory, which will be moved over to Maven 2 as well 3. Therefore, the immediate goal for the wars is to have all of them reside in apps/, making building and testing easier 4. The end goal for the example wars will be to allow each module to perhaps define its own sample Struts module, with a Maven plugin that collects all the samples into one war. Cocoon does this with their blocks with good effect. It makes it easy for users to see all the possibilities without having to deploy a bunch of wars. As a result, we'll be doing some restructuring, particularly to Faces. Please let us know soon if anyone has any objections. Don Martin Cooper wrote: On 4/5/06, James Mitchell [EMAIL PROTECTED] wrote: I'd like to address some the current [action 1] build issues. Now that we've simplified the directory structure (thanks Don!), I'd like to spend some time on our build process. Please comment on the following, if I don't hear back soon I'll go ahead and take care of these... 1. sample apps action/apps/blank - I think we should remove the dependency on tiles, blank should not be an empty showcase for how to work with tiles. Fine with me. 2. Dependency declarations are inconsistent. For example, some Maven 1 targets end with... ... ... struts-tiles-1.3.1-SNAPSHOT.jar (try downloading from http:// struts.apache.org/) struts-core-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/) struts-extras-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/download.cgi) struts-taglib-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/download.cgi) ... ... So, is it 1.3.1 or 1.3.2? Is it download.cgi or the root of the project site? The project root seems less likely to move. ;-) And a few more questions: Q. We have a Maven 1 and Maven 2 build available, is this really necessary? Why not just go with Maven 2? If we have, or can get, our M2 build to at least the functionality of our M1 build, I'd be in favour of dumping the M1 build now. Q. I know there was apprehension about moving to Maven 2 a while back because of the lack of plugins compared to maven 1. Is this still the case? I'll trust Wendy on this one, since I haven't gone and compared what we have in M1 to what's available in M2. The array of plugins available for M2 is mind-boggling, though. Q. How many other committers are committed to learning and perfecting our Maven 1 and/or 2 builds? I have been spending a *lot* of time with M2 in my day job recently, including writing some tricky custom Mojos, so I'm certainly up for helping out with the M2 build. As for M1, now that I've got my head around M2, I'd prefer not to try to keep two versions of Maven in my head. ;-) -- Martin Cooper Q. What is the difference between these? sandbox/tiles/tiles-documentation sandbox/tiles-documentation I have more, but I'll fire this off for now... -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED]
Re: [action1] cleaning up the build
Interesting that you would put [action1] in when discussing struts but not [faces] when discussing faces. This is a real upside down deal, isn't it? On 4/5/06, James Mitchell [EMAIL PROTECTED] wrote: I'd like to address some the current [action 1] build issues. Now that we've simplified the directory structure (thanks Don!), I'd like to spend some time on our build process. Please comment on the following, if I don't hear back soon I'll go ahead and take care of these... 1. sample apps action/apps/blank - I think we should remove the dependency on tiles, blank should not be an empty showcase for how to work with tiles. 2. Dependency declarations are inconsistent. For example, some Maven 1 targets end with... ... ... struts-tiles-1.3.1-SNAPSHOT.jar (try downloading from http:// struts.apache.org/) struts-core-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/) struts-extras-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/download.cgi) struts-taglib-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/download.cgi) ... ... So, is it 1.3.1 or 1.3.2? Is it download.cgi or the root of the project site? And a few more questions: Q. We have a Maven 1 and Maven 2 build available, is this really necessary? Why not just go with Maven 2? Q. I know there was apprehension about moving to Maven 2 a while back because of the lack of plugins compared to maven 1. Is this still the case? Q. How many other committers are committed to learning and perfecting our Maven 1 and/or 2 builds? Q. What is the difference between these? sandbox/tiles/tiles-documentation sandbox/tiles-documentation I have more, but I'll fire this off for now... -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Re: [action1] cleaning up the build
On 4/14/06, James Mitchell [EMAIL PROTECTED] wrote: I spent some time yesterday looking at what's left wrt the sample apps. Thanks. :) struts-mailreader - good to go (Does the web tests work for this yet?) They're done with Canoo Webtest, right? I didn't find a m2 plugin for it, but we could probably do it with the antrun plugin. (See action/apps for an example that copies files. It should be in a profile with id 'perform-itest' so it runs with the others, and not during the normal build.) And so far I have this to deploy all the apps and make sure the index page for each one will load: http://wiki.wsmoak.net/cgi-bin/wiki.pl?StrutsAppsTest I also spent some time looking at the site docs. They all seemed to run ok, and although I had to run the top level separately from action1, they look fine. So, what's next? Pasted from an earlier message: I think Struts Action needs a 'top level' site: struts/action/trunk/src/site/*. If that were published to s.a.o/struts-action, then struts-core, struts-taglib, etc., could go below it. (For example: http://struts.apache.org/struts-shale/shale-tiger/ ). ... Each pom needs a distributionManagement/site section with the correct path. (See struts/pom/pom.xml for an example.) I'd like to move the src/conf and conf/java files into src/main/resources and remove the resource tags from the pom, also. From the chat log... Yes, there's an archetype for Struts Blank in the sandbox. It probably needs some work, removing the Tiles dependency and changing struts-action - struts-core, but otherwise it can come up to action/archetypes/struts-blank. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action1] cleaning up the build
Another one from the chat log... to get the Javadoc generated for the site, add this to action/pom.xml: reporting plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId ... (and repeat for other reporting plugins. Checkstyle? PMD?) Don mentioned wanting to get the docs into the assembly. Right now it only has the -javadocs jars. Without site aggregation working, though, I don't know how easy it will be. For the build itself, we should be using dependencyManagement at the top level to control version numbers, and only declaring groupId/artifactId for dependencies in the modules. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action1] cleaning up the build
On 4/5/06, James Mitchell [EMAIL PROTECTED] wrote: So, is it 1.3.1 or 1.3.2? The versions are correct. Struts Tiles has a separate build and is at 1.3.1-SNAPSHOT, having had a 1.3.0 test build. The Struts Action jars (core, el, extras, taglib...) will be versioned together and should be at 1.3.2-SNAPSHOT. (There was a 1.3.1 test build for struts-action, so that number has been used.) Q. I know there was apprehension about moving to Maven 2 a while back because of the lack of plugins compared to maven 1. Is this still the case? While I haven't tried to build the entire Struts Action project with m2, (yet!) I have been watching MyFaces' Maven build. I think that project is similar enough (taglibs, webapps, etc.,) that if they're okay with m2, we should be too. As a bonus, we can borrow from the MyFaces build... which I did. :) Take a look at action/assembly and feel free to make changes. I just took the myfaces-core assembly and removed things until it started working. (Be sure to build struts-core again before trying the assembly.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action1] cleaning up the build
On 4/6/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/5/06, James Mitchell [EMAIL PROTECTED] wrote: So, is it 1.3.1 or 1.3.2? The versions are correct. Struts Tiles has a separate build and is at 1.3.1-SNAPSHOT, having had a 1.3.0 test build. The Struts Action jars (core, el, extras, taglib...) will be versioned together and should be at 1.3.2-SNAPSHOT. (There was a 1.3.1 test build for struts-action, so that number has been used.) Minor correction. If Struts Action is going to depend on Struts Tiles, it should be struts-tiles 1.3.0, not a snapshot. I fixed the dependency in struts-blank, though I see you suggested removing it entirely. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action1] cleaning up the build
James Mitchell wrote: I'd like to address some the current [action 1] build issues. Now that we've simplified the directory structure (thanks Don!), I'd like to spend some time on our build process. Please comment on the following, if I don't hear back soon I'll go ahead and take care of these... 1. sample apps action/apps/blank - I think we should remove the dependency on tiles, blank should not be an empty showcase for how to work with tiles. +1 2. Dependency declarations are inconsistent. For example, some Maven 1 targets end with... ... ... struts-tiles-1.3.1-SNAPSHOT.jar (try downloading from http:// struts.apache.org/) struts-core-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/) struts-extras-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/download.cgi) struts-taglib-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/download.cgi) ... ... So, is it 1.3.1 or 1.3.2? Is it download.cgi or the root of the project site? 1.3.2 for struts action 1. I'd say the project root for the download site. And a few more questions: Q. We have a Maven 1 and Maven 2 build available, is this really necessary? Why not just go with Maven 2? If Maven 2 can be made to work by Friday, I'm fine with Maven 2. The bottom line is I want to get out a test build this weekend, having put this reorg and build stuff behind us. Q. I know there was apprehension about moving to Maven 2 a while back because of the lack of plugins compared to maven 1. Is this still the case? Honestly, I don't care as long as it works and does everything the current build does for us now. Q. How many other committers are committed to learning and perfecting our Maven 1 and/or 2 builds? I'll help in any way I can with either build; I just want to get it all working ASAP. Q. What is the difference between these? sandbox/tiles/tiles-documentation sandbox/tiles-documentation No idea, but I'd vote for getting rid of any tiles in the sandbox. If a new version of tiles is in the works, make a branch off the tiles project. That's what branches are for. Thanks for jumping in! Don I have more, but I'll fire this off for now... -- James Mitchell - 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]
Re: [action1] cleaning up the build
Ok, I'm working with Wendy to do the Maven 2 conversion. Here is the plan we have decided on: 1. All the jar artifacts (core, taglib, el, faces, scripting, extras) get their own directory and pom 2. All the war artifacts, including the example apps from modules like faces and scripting, will be moved into the apps/ directory, which will be moved over to Maven 2 as well 3. Therefore, the immediate goal for the wars is to have all of them reside in apps/, making building and testing easier 4. The end goal for the example wars will be to allow each module to perhaps define its own sample Struts module, with a Maven plugin that collects all the samples into one war. Cocoon does this with their blocks with good effect. It makes it easy for users to see all the possibilities without having to deploy a bunch of wars. As a result, we'll be doing some restructuring, particularly to Faces. Please let us know soon if anyone has any objections. Don Martin Cooper wrote: On 4/5/06, James Mitchell [EMAIL PROTECTED] wrote: I'd like to address some the current [action 1] build issues. Now that we've simplified the directory structure (thanks Don!), I'd like to spend some time on our build process. Please comment on the following, if I don't hear back soon I'll go ahead and take care of these... 1. sample apps action/apps/blank - I think we should remove the dependency on tiles, blank should not be an empty showcase for how to work with tiles. Fine with me. 2. Dependency declarations are inconsistent. For example, some Maven 1 targets end with... ... ... struts-tiles-1.3.1-SNAPSHOT.jar (try downloading from http:// struts.apache.org/) struts-core-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/) struts-extras-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/download.cgi) struts-taglib-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/download.cgi) ... ... So, is it 1.3.1 or 1.3.2? Is it download.cgi or the root of the project site? The project root seems less likely to move. ;-) And a few more questions: Q. We have a Maven 1 and Maven 2 build available, is this really necessary? Why not just go with Maven 2? If we have, or can get, our M2 build to at least the functionality of our M1 build, I'd be in favour of dumping the M1 build now. Q. I know there was apprehension about moving to Maven 2 a while back because of the lack of plugins compared to maven 1. Is this still the case? I'll trust Wendy on this one, since I haven't gone and compared what we have in M1 to what's available in M2. The array of plugins available for M2 is mind-boggling, though. Q. How many other committers are committed to learning and perfecting our Maven 1 and/or 2 builds? I have been spending a *lot* of time with M2 in my day job recently, including writing some tricky custom Mojos, so I'm certainly up for helping out with the M2 build. As for M1, now that I've got my head around M2, I'd prefer not to try to keep two versions of Maven in my head. ;-) -- Martin Cooper Q. What is the difference between these? sandbox/tiles/tiles-documentation sandbox/tiles-documentation I have more, but I'll fire this off for now... -- James Mitchell - 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]
Re: [action1] cleaning up the build
On 4/6/06, Don Brown [EMAIL PROTECTED] wrote: Ok, I'm working with Wendy to do the Maven 2 conversion. Here is the plan we have decided on: 1. All the jar artifacts (core, taglib, el, faces, scripting, extras) get their own directory and pom 2. All the war artifacts, including the example apps from modules like faces and scripting, will be moved into the apps/ directory, which will be moved over to Maven 2 as well 3. Therefore, the immediate goal for the wars is to have all of them reside in apps/, making building and testing easier 4. The end goal for the example wars will be to allow each module to perhaps define its own sample Struts module, with a Maven plugin that collects all the samples into one war. Cocoon does this with their blocks with good effect. It makes it easy for users to see all the possibilities without having to deploy a bunch of wars. As a result, we'll be doing some restructuring, particularly to Faces. Please let us know soon if anyone has any objections. Let me know if you need any help on the Faces part. I'm fine with the goals articulated above. Don Craig Martin Cooper wrote: On 4/5/06, James Mitchell [EMAIL PROTECTED] wrote: I'd like to address some the current [action 1] build issues. Now that we've simplified the directory structure (thanks Don!), I'd like to spend some time on our build process. Please comment on the following, if I don't hear back soon I'll go ahead and take care of these... 1. sample apps action/apps/blank - I think we should remove the dependency on tiles, blank should not be an empty showcase for how to work with tiles. Fine with me. 2. Dependency declarations are inconsistent. For example, some Maven 1 targets end with... ... ... struts-tiles-1.3.1-SNAPSHOT.jar (try downloading from http:// struts.apache.org/) struts-core-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/) struts-extras-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/download.cgi) struts-taglib-1.3.2-SNAPSHOT.jar (try downloading from http:// struts.apache.org/download.cgi) ... ... So, is it 1.3.1 or 1.3.2? Is it download.cgi or the root of the project site? The project root seems less likely to move. ;-) And a few more questions: Q. We have a Maven 1 and Maven 2 build available, is this really necessary? Why not just go with Maven 2? If we have, or can get, our M2 build to at least the functionality of our M1 build, I'd be in favour of dumping the M1 build now. Q. I know there was apprehension about moving to Maven 2 a while back because of the lack of plugins compared to maven 1. Is this still the case? I'll trust Wendy on this one, since I haven't gone and compared what we have in M1 to what's available in M2. The array of plugins available for M2 is mind-boggling, though. Q. How many other committers are committed to learning and perfecting our Maven 1 and/or 2 builds? I have been spending a *lot* of time with M2 in my day job recently, including writing some tricky custom Mojos, so I'm certainly up for helping out with the M2 build. As for M1, now that I've got my head around M2, I'd prefer not to try to keep two versions of Maven in my head. ;-) -- Martin Cooper Q. What is the difference between these? sandbox/tiles/tiles-documentation sandbox/tiles-documentation I have more, but I'll fire this off for now... -- James Mitchell - 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]
