Re: INFRA-1811
On 30/01/2009, at 11:47 AM, Wes Wannemacher wrote: On Thursday 29 January 2009 19:08:59 Brett Porter wrote: Hi folks, This issues was raised with infrastructure last year as Bamboo couldn't post to comm...@struts. With the changes to use Hudson, is it still needed, or are you able to post your notifications now? - Brett I sent a blank message to dev-allow-subscribe-hudson=hudson.zones.apache@struts.apache.org but didn't hear anything back from ezmlm... Do I need mod permissions or something? Yes, you would (otherwise anyone would let themselves be allowed :) Anyhow, I went ahead and told hudson to fail a build to see if the email would come through and it did not :( it's not in the queue either - are you sure it was sent? Anyway, this discussion was about comm...@struts. If you are going to use d...@struts then there won't be an issue and it can be closed. IS that the case? - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: INFRA-1811
On 30/01/2009, at 1:25 PM, Wes Wannemacher wrote: I kind of figured, but thought it couldn't hurt to try. Brett, can you look in and see who is configured as a mod for dev@ commits@, etc. ? I think the problem we've had in the past is that the current set of mods have been too busy with their day jobs to help out. For dev, Rene Gielen, Don Brown, Ted Husted, Dave Newton. Please file an infra request in JIRA if you need some changes. For commits, it isn't relevant - there's no moderation, it's just locked down to commit messages (and this issue is whether to also allow issues from another source). - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: INFRA-1811
gmail smtp vs ezmlm - I added myself to the allow and changed my smtp server :) - Brett On 30/01/2009, at 2:16 PM, Dave Newton wrote: Wes Wannemacher wrote: Whether we do commits@ or dev@, it doesn't matter to me, I'll leave that up to the group. IIUC, the issue is probably lack of mod access for any of the active devs. FWIW, I'm been modding this entire conversation--for some reason they're all coming as needing moderation. Hrmph. (I've actually been a little surprised at the modding volume.) Dave - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: No offense, Don Co.
On 31/12/2008, at 4:42 PM, Wes Wannemacher wrote: There are some open source CI systems, and since our build is pretty simple, thanks to Maven, even a cron job could suffice. I'll come back to this in January and see what I can throw together hardware/software wise just to give more options... Apache already has two of them running (Continuum, at vmbuild.apache.org, and Hudson, at hudson.zones.apache.org) that you can simply request access to. Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Heads up on maven-jar-plugin change
... but you probably don't want the default, and should specify your own. :) I think the defaults in this version are more sensible than last time, where they were blatantly incorrect. But they probably still require some customisation. - Brett On 05/09/06, Wendy Smoak [EMAIL PROTECTED] wrote: Version 2.1 of the Maven Jar Plugin was just released, and the default jar file manifest has changed. See: http://jira.codehaus.org/browse/MJAR-57 If you want the Specification and Implementation details listed, this configuration needs to be added to the pom: plugin artifactIdmaven-jar-plugin/artifactId configuration archive manifest addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries addDefaultImplementationEntriestrue/addDefaultImplementationEntries /manifest /archive /configuration /plugin -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org Better Builds with Maven book - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Heads up on maven-jar-plugin change
http://maven.apache.org/guides/mini/guide-manifest.html On 05/09/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/4/06, Brett Porter [EMAIL PROTECTED] wrote: ... but you probably don't want the default, and should specify your own. :) I think the defaults in this version are more sensible than last time, where they were blatantly incorrect. But they probably still require some customisation. This at least gets us back where we were until the plugin site is updated so I can figure out how to customize it. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org Better Builds with Maven book - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] RetroWeaver or RetroTranslator
From those that have been using it, I've heard retrotranslator was more workable for this scenario. We have plugins for both retroweaver and retrotranslator at mojo.codehaus.org: http://mojo.codehaus.org/retrotranslator-maven-plugin/ Jason Dillon has been working on making that more functional recently. There's probably more work to go, but it should actually be quite straight forward to utilise the dependency list and the lifecycle to produce these quite easily. Is there a JIRA issue I can watch for this, or should I create one? Cheers, Brett On 25/07/06, Don Brown [EMAIL PROTECTED] wrote: Yeah, exactly. It will probably involve using the antrun plugin, but unless someone really wants to work on that right now, it'll have to be another entry on the todo list. Don Ted Husted wrote: On 7/24/06, Don Brown [EMAIL PROTECTED] wrote: I think we should follow Tim's lead by using RetroTranslator, however, it shouldn't hold up the 2.0.0 release. I could finesse the 2.0.0 distribution, but I wonder if we are going be able to make using RT a standard feature of the Maven assemblies and nightly builds. -Ted. - 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] -- Apache Maven - http://maven.apache.org Better Builds with Maven book - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts1] mvn site:run
On 07/07/06, Wendy Smoak [EMAIL PROTECTED] wrote: I haven't seen it on a non-Windows system, but that's because I'm on WinXP + Cygwin. :) http://www.vmware.com/products/server/ :) BTW, I just sanity checked that there wasn't a toLower or anything in there, but I'm still not prepared to rule out me doing something dumb in the plugin code. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
(from the peanut gallery) How about: repos/asf/struts/branches/struts-1.3/... repos/asf/struts/trunk (2.0, 2.1, 3.0 goes here) It's not like you're the first project here to have had a 1.3 v 2.0 issue :) http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/ Cheers, Brett On 30/06/06, Ted Husted [EMAIL PROTECTED] wrote: Or, in the interest of brevity, even repos/asf/struts/s1 repos/asf/struts/s2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 and Functional/Integration Tests
On 06/06/06, Craig McClanahan [EMAIL PROTECTED] wrote: Maven2 needs to support integration testing as a first class notion in the architecture of what you envision a project to be. It may not have been clear enough, but that's exactly what I meant in my last email. I thought this is what the wiki page discussed - if you think something is missing there, let me know. Somehow I missed the correct issue I was thinking of, MNG-1381, so I've linked that now instead. I'm just trying to consolidate this. I can assure you it is the issue you are thinking of - sorry for the confusion, re-reading I see MNG-591 is a specific use case of integration testing and not very helpful. It's not just webapps .. you've got the same sort of issue with EJBs, or web services, or anything that gets deployed in a container. Unit tests just don't give you the confidence you need that the application will actually work. I've seen too many cases where all the unit tests on a webapp all pass with flying colors, but it throws an HTTP 500 on the welcome page because of a stupid coding error in the JSP page that wasnt' tested with the unit tests. Yes, I'm well aware of that. What's needed is a complete additional test environment, with its own lifecycle, and its own classpath (i.e. dependencies tagged to this scope so you only load things like HttpUnit or HtmlUnit here). If integration tests exist, they should be part of the default mvn install processing, just like unit tests are, unless it is explicitly disabled. Don't pretend that there is only one kind of test!!! Again, what I was getting at. This was discussed at length on the Maven dev list and is summarised on the wiki page. Otherwise, you guys are not being serious about trying to encouraging best practices in build environments :-(. Of course we are. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuous integration for Struts
It depends :) I'm happy to hand out access to it. There are a couple of gotchas though. 1) there's only 20G of disk space in total, so we'll need to be proactive on keeping that in check 2) Continuum doesn't have a lot of features for manging multiple groups of people in one instance (all the projects are on one dashboard). So we'll need to live with that. Thankfully, Patrick has volunteered to help :) 3) We might occasionally want to try newer continuum builds there since it isn't a production grade service, which might cause an interruption. If these are acceptable, then it'd be great to work on it together. I think infra@ would be happy not to have yet another Continuum running on the zone machine. BTW, Continuum is now using WW 2.2.2 with a view to moving to SAF 2.0. We'd welcome anyone from Struts that is interested in helping work on Continuum itself :) Cheers, Brett On 06/06/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/25/06, Patrick Lightbody [EMAIL PROTECTED] wrote: Do we have something like Continuum setup for Struts? If not, we should. What's the process to kick this off? Take two: Brett mentioned on commons-dev that vmbuild.apache.org is available for Commons nightly builds CI. * http://www.nabble.com/vmbuild.apache.org-now-available-p4708847.html Brett, is this going to be available for other projects at some point? We've been talking about setting up Continuum in the Struts zone, but it makes more sense to use a shared instance, if one is available. Patrick Lightbody has volunteered to set up the Struts builds. Can you please let us know if we'll be able to use this, or if we should go ahead in our own zone? Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org Better Builds with Maven book - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 and Functional/Integration Tests
It'll probably get closed as a duplicate, but thanks for the input. It *should* still be possible to achieve what you want currently (I thought Vincent's chapter discussed that, but I don't might be mistaken). It may take some effort, though, and I'm not sure of any existing examples. The 'integration-test' phase was meant to be a general hook to facilitate this where possible. We've always wanted to better support this in Maven. The problem is that we didn't come to any agreement on what it should work like by the time 2.0 was released, so it's something we're looking at for 2.1 instead. I haven't looked at the page Wendy pointed to recently, but it was meant to capture a summary of the discussion. I'll have to take some time to check that it is complete. The upshot of this is that we agree it should work, and if you have any ideas for how it should work then we'd be glad to hear them. Cheers, Brett On 06/06/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/5/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/5/06, Craig McClanahan [EMAIL PROTECTED] wrote: If I'm reading 'Better Builds With Maven correctly, it seems that the recommended practice for functional or system integration tests for webapps (i.e. where you deploy the app to a server and then execute HTTP requests and examine the result) is to build a separate functional-tests module per webapp. Yuck. Is that the only way to do it? I was spoiled in my previous build.xml scripts to be able to run ant install systest on a webapp module and have it deploy my app plus execute the integration tests immediately, with the tests themselves being in a separate source directory (my convention was src/systest) in the same project. Although Maven 2.0 has build lifecycle phases for both 'test' and 'integration-test', it doesn't seem to handle doing both of them in the same module. Surefire looks at the build/testSourceDirectory to find the test sources -- there is no integrationTestSourceDirectory, and no way that I'm aware of to have two executions of Surefire in the same module that use different source directories. There's some information on the StrutsMaintenanceMaven wiki page, including a link to a page on the Maven wiki where integration testing strategies are being worked out: http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies For a while it seemed like Vincent was going to be allowed to make some changes in Maven 2.0, but nothing has happened recently, and one of the issues linked to from that wiki page is marked 'fix for 2.1.1'. For Struts Action, all of the integration tests live in action/integration/apps-it, and the plugin executions are wrapped in a profile so they don't run unless you use -Pperform-itest. I agree that having the tests in a separate module isn't ideal, but I think we'll have to live with it for a while. BTW, here's the TestSetup class that uses Cargo to start Tomcat and deploy the apps: http://svn.apache.org/repos/asf/struts/action/trunk/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java I'll do my part[1] to encourage positive change in this regard. -- Wendy Craig [1] http://jira.codehaus.org/browse/MNG-2344 -- Apache Maven - http://maven.apache.org Better Builds with Maven book - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Separate lists for notifications vs. discussion
Martin was the one that knew the steps - I've not done anything with the wikidiffs myself. :) Cheers, Brett On 5/2/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/1/06, Martin Cooper [EMAIL PROTECTED] wrote: On 5/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/30/06, Brett Porter [EMAIL PROTECTED] wrote: My bad - fixed. Sorry for the inconvenience. I have also subscribed all committers to the 'allow' list for commits to save the moderators some time. Thanks, Brett! We also need to send the Wiki diffs to commits@ instead of [EMAIL PROTECTED] Is that something that someone here can fix, or do I need to open another issue with infrastructure? I know how to do this, but I don't have the perms. ;-( It seems you need either apmail or root to change it, so I guess a ticket is in order. Brett, It so happens I have apmail karma ... if you want to forward me the necessary steps I should be able to take care of this. Craig -- Martin Cooper I'll update mail.xml with the new list descriptions tonight. 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: [PROPOSAL] Separate lists for notifications vs. discussion
My bad - fixed. Sorry for the inconvenience. I have also subscribed all committers to the 'allow' list for commits to save the moderators some time. Cheers, Brett On 5/1/06, James Mitchell [EMAIL PROTECTED] wrote: Same here. -- James Mitchell On Apr 30, 2006, at 12:45 PM, Wendy Smoak wrote: On 4/30/06, James Mitchell [EMAIL PROTECTED] wrote: Not long after this, the moderation emails came in. For issues@ or [EMAIL PROTECTED] I received a couple of moderation emails for issues, (and I see someone already let them through,) but my commit message from yesterday bounced with: Hi. This is the qmail-send program at apache.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: ezmlm-send: fatal: key does not exist ezmlm-gate: fatal: fatal error from child And I haven't seen a commit message (other than the one I forwarded) since Saturday morning. :/ -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Separate lists for notifications vs. discussion
On 4/27/06, Wendy Smoak [EMAIL PROTECTED] wrote: However, 'notifications@' is something I'd like to see for Continuum. :) With that addition, we'd have the same setup that Maven does: http://maven.apache.org/mail-lists.html For the record, I think this is working great for us. One of the great benefits of everything being separate is that you can now browse the dev list and only see discussion. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: closing and reopening jira issues
We actually eliminated the resolve step since weren't using it independantly of resolve, however this doesn't affect the other part. I'm not exactly sure of the technical details of how we made editing possible when it was resolved/closed - but I can find out. It doesn't actually transition to any different steps in between. Cheers, Brett On 4/27/06, Don Brown [EMAIL PROTECTED] wrote: What does the end workflow look like? Do you just add a transition to resolve to the close step? Don Brett Porter wrote: Hi, I've noticed that there have been 1 or 2 mails recently on this list to reopen and close jira issues. Am I correct in assuming this is to be able to edit the fix version or other details? If this will be a regular occurrence, I recommend working with the jira admins to create a custom workflow. We've done that in Maven and it allows you to edit issues that are closed with appropriate permissions. It's a big timesaver if used responsibly. just my $A0.02 Cheers, Brett - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
are the apis with the other javadoc going to be in a separate module? This should make it easy to produce javadoc from there, and then go on to produce the aggregated javadoc for the others. - Brett On 4/16/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/15/06, James Mitchell [EMAIL PROTECTED] wrote: Craig wrote I'll want to experiment with ways to get combined javadocs out of these artifacts (although probably two sets ... Can we do this with custom assemblies? Without trying it, I don't think so, because it's more than just copying files around. The Javadoc tool needs to create the frames and indexes so that everything is linked together. I think it will need two reportSets, so the Javadoc plugin runs twice with different configuration. Maybe something like this, which runs both the regular Javadoc doclet and the UMLGraph one: http://wiki.wsmoak.net/cgi-bin/wiki.pl?UMLGraph And here's a link to some work that I did last year, which includes pom.xml files and a script to rearrange Shale into Maven 2's preferred structure. I stopped in late November, so it doesn't include Shale Tiger or anything after that. http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleMaven2#build -- 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]
