Re: [vote] Request Graduation to a TLP
+1 -john On Feb 5, 2008, at 6:06 PM, Emmanuel Venisse wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged. --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Re: Project Group Notifiers
I think since it's Continuum and not a generic Maven build (i.e. where you added the POM can be taken into consideration, where with Maven you have to consider any module as a possible entry point to the build), it should be okay. My only slight reservation would be if group-level notifiers can act differently than project-level notifiers. If that's the case, then the behavior of Continuum builds will differ based on which POM is used to add a hierarchy, since the child POMs that are also parents will have their notifiers added at the project level, and would behave accordingly. Also, if continuum databases ever became exportable in any way, this could produce data inconsistencies with exports from other Continuum instances that added a hierarchy of POMs from a different starting point. I don't think either of those would be an issue, so I don't see this as a problem. Just my $0.02US -john On 10/24/06, Jesse McConnell [EMAIL PROTECTED] wrote: I have been working at this problem off and on for a few days and have a bit of a stumbling block I would like a bit of feedback on.. build definitions where easier for this since they had no equivalent POM linkage...but thats a bit of an issue with the notifiers I am finding. My original assumption was that any notifiers declared in the pom that I am loading in as an m2 project would be initialized as a group notifier. This becomes a minor issue as the way things stand right now I'll have to pass annoying groupPom boolean status into parts of the loading mechanism that I really don't want to. But then I just got to thinking that this only addresses it part way. Basically I wanted to ask if people were comfortable with the following statement. notifiers defined in the pom being loaded in as the project group pom ( the one input into the Add M2 Project page) and the notifiers defined in the parents of that pom are all group lvl notifiers. any notifiers defined below that point will be attached as individual project notifiers. In the case of notifiers configured in poms that are the parents of sub-modules/projects (but are still children of the top lvl continuum project group pom) will be added to each of the child poms below that. an example might help P1 - P2 P2 - P3 P2 - P4 P4 - P5 P4 - P6 for P1-6, if P2 where the pom loaded into continuum as the project group, then * notifiers in P1 and P2 are group notifiers * notifiers in P4 are added to P4,5,6 as project notifiers Would this work as a hard and fast rule for notifiers? jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] rbac-integration branch merge to trunk
+1 -john Jesse McConnell wrote: Brett suggested we do a vote for this today so I figured I would just do that now. [-1/0/+1] vote will be open for 72 hours Pulling from the other mail, this branch was pulled a bit over a week ago to test out the plexus-security integration with continuum. Some of the added features are * full separation between application webapp and security (lightweight integration). * proper modularization for security components (authentication, authorization, policy, system, web, etc...) * rbac (role based access control) authorization provider. * full user management war overlay (using healthy chunk of maven-user to make it happen) * toggle-able guest user authorization. * remember me and single sign on authentication. * forced admin account creation (through use of interceptor) * key based authentication (remember me, single sign on, new user validation emails, and password resets). * http auth filters (basic and digest). * aggressive plexus utilization. * aggressive xwork / webwork integration. * xwork interceptors for force admin, auto login (remember me), secured action, and environment checks. * secured actions for all of the /security namespace and at least one continuum secured action (these are enforced by the pssSecureActionInterceptor) * all the password validation, user management stuff (again maven-user origins) * continuum-security artifact containing the actual static and dynamic roles, and a continuum role manager that merges permissions to the core system, user, and guest users * ifAuthorized, ifAnyAuthorized, elseAuthorized jsp tags. * placeholders for ldap authentication, authorization and user details retrieval using plexus ldap components * ability to re-use Acegi for authentication +1 from me cheers, jesse -- John Casey --- Maven Developer (http://maven.apache.org) --- Website: http://www.commonjava.org Blog: http://www.ejlife.net/blogs/john
Re: Distributed Continuum (GBuild)
+1 This is an important feature for Continuum. I can't wait to see it! -john Jason van Zyl wrote: Hi, I have been talking with David Blevins about moving the GBuild code from Geronimo over to Continuum proper. GBuild is a version of Continuum that works in a distributed fashion. GBuild was created to test the Geronimo TCK across many different platforms with many different configurations and have the results all aggregated back on a master machine. So what I would like to propose is to move the code from GBuild over into Continuum proper and give David Blevins and Kevan Miller commit access. They are both committers on the Geronimo project and are familiar with this distributed code and will continue to work on the code once in Continuum. This is very exciting! Here's my +1 Jason van Zyl
[jira] Updated: (CONTINUUM-510) big year schedule 2099 prevents continuum from startup
[ http://jira.codehaus.org/browse/CONTINUUM-510?page=all ] John Casey updated CONTINUUM-510: - Fix Version: (was: 1.1-alpha-1) 1.0.3 big year schedule 2099 prevents continuum from startup Key: CONTINUUM-510 URL: http://jira.codehaus.org/browse/CONTINUUM-510 Project: Continuum Type: Bug Components: Web interface, Core system Versions: 1.0.2 Environment: xp,starteam Reporter: Dan Tran Assignee: Emmanuel Venisse Fix For: 1.0.3 - Create a scheduler with year 2099 ( ex 0 15 10 * * ? 2100 ) Continuum does throw exception letting user know it will never got fired but still add it to dabase - Assign the newly create scheduler to a project - restart - Continuum webapp never get started The only solution i can think of is to remove database and start from scratch According to Evenisse, Quart does not allow year 2099 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-531) Add back the build now button on the view project page.
[ http://jira.codehaus.org/browse/CONTINUUM-531?page=all ] John Casey updated CONTINUUM-531: - Fix Version: (was: 1.1-alpha-1) 1.0.3 Add back the build now button on the view project page. --- Key: CONTINUUM-531 URL: http://jira.codehaus.org/browse/CONTINUUM-531 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.2 Reporter: Trygve Laugstol Assignee: nick gonzalez Fix For: 1.0.3 Attachments: CONTINUUM-531.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-567) A build must be launched if we have changes since last build (for same build definition) and not only if we have detected changes when we run scm update commad
[ http://jira.codehaus.org/browse/CONTINUUM-567?page=all ] John Casey updated CONTINUUM-567: - Fix Version: (was: 1.1-alpha-1) 1.0.3 A build must be launched if we have changes since last build (for same build definition) and not only if we have detected changes when we run scm update commad --- Key: CONTINUUM-567 URL: http://jira.codehaus.org/browse/CONTINUUM-567 Project: Continuum Type: Improvement Components: Core system Versions: 1.0.2 Reporter: Emmanuel Venisse Assignee: nick gonzalez Fix For: 1.0.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-354) Need a way to poll for new projects
[ http://jira.codehaus.org/browse/CONTINUUM-354?page=all ] John Casey updated CONTINUUM-354: - Fix Version: (was: 1.1-alpha-1) 1.0.3 Need a way to poll for new projects --- Key: CONTINUUM-354 URL: http://jira.codehaus.org/browse/CONTINUUM-354 Project: Continuum Type: Improvement Versions: 1.0-beta-1 Reporter: Matthew Beermann Assignee: nick gonzalez Fix For: 1.0.3 The feature where Continuum can populate its build list from a URL is wonderful; it'd be even more wonderful if it could remember that URL and poll it periodically. We have a master build list of all projects that we'll use to initially populate the build database; but ideally we could simply add a new project to that in CVS and have Continuum just pick it up. This is a feature that we've (somewhat painfully) managed to implement in CruiseControl, and it's a must-have if we're going to switch over... this might or might not depend on CONTINUUM-330. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-496) End Time contains junk value when I forced a build to run
[ http://jira.codehaus.org/browse/CONTINUUM-496?page=all ] John Casey updated CONTINUUM-496: - Fix Version: (was: 1.1-alpha-1) 1.0.3 End Time contains junk value when I forced a build to run - Key: CONTINUUM-496 URL: http://jira.codehaus.org/browse/CONTINUUM-496 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Reporter: John Sisson Assignee: Emmanuel Venisse Priority: Minor Fix For: 1.0.3 The following is from the build history when it was building. Note the end time on the first line: Dec 1, 2005 10:23:11 PM Dec 31, 1969 4:00:00 PM BuildingResult 22Dec 1, 2005 10:00:18 PM Dec 1, 2005 10:06:51 PM Success Result 21Dec 1, 2005 7:00:16 PM Dec 1, 2005 7:03:57 PM Success Result This occurred on http://ci.gbuild.org/continuum/servlet/continuum running a 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Proposal] Continuum refactoring
While I do like the idea of splitting up any monolithic code in the DefaultContinuum class, I don't support splitting data-access code from itself. IMO, breaking data-access stuff by model-class is asking for trouble, since it doesn't allow a good mapping of data-access functions for managing relationships between multiple model classes. It think we can still gain a lot by separating the DAO stuff into a small number of DAO classes (maybe only one? definitely not one-per-model-class), and separating other bits of logic into coherent classes that are controlled by the DefaultContinuum class. For DAOs we need to avoid both the case where all DAO functions are stuffed in a single class Just Because - making it hard to maintain by sheer size - and the case where DAO functions dealing with object-object relations is shoved into a class where it doesn't make sense (i.e. on one of the classes' DAOs and not the other). -j Trygve Laugstøl wrote: On Wed, 2005-12-14 at 14:58 -0800, Carlos Sanchez wrote: On 12/14/05, Trygve Laugstøl [EMAIL PROTECTED] wrote: I still disagree with splitting up the ContinuumStore into a set of DAOs. I've never seen the advantage of having a single DAO for each domain object. They will be reusable in other applicaitons. If we're thinking about creting other applications, like repository manager, we'll share a lot of common objects between them. I have yet to see an example of this idea working in real life. I understand that you'd want to manage different sets of objects, but like in Continuum the Project and Build objects are to tightly coupled that you can't possibly store Project objects in one database and the Build objects in another. -- Trygve
Design - Replacing Continuum's Web Framework
Hi everyone, We've been talking about this for quite awhile in various channels, and I wanted to take a few minutes and formalize the discussion. I'll capture the highlights of this discussion in the wiki afterwards. I'll start by posting my own thoughts, and let you all respond. Up to this point, Continuum has been built on a web framework called Summit, which is part of the Plexus project, and using Velocity as the page rendering technology. Summit is still a very young project, and as a result has its problems. Given the proliferation of web frameworks out there, it seems natural to wonder whether we couldn't find something more mainstream and mature that will fit our needs. The key goal here is to make the web tier as easy to understand as possible by the widest possible audience, without sacrificing anything in the way of quality. To that end, criteria might include: * tool support * maturity in the form of multiple final releases (or at least one) * good integration with JSP (it's the most widely-used rendering technology out there for java) * ready availability of good documentation * integration with a decent security library (think acegi) * others? Another big concern is that we need to be able to make this web framework integrate with Plexus without too much funny business. I don't expect that to be a big problem, but worth mentioning. I know that a certain amount of work has been done by Trygve and Emmanuel to get WebWork running inside Plexus. Is this the best framework? A quick check of Amazon showed three books, only one of which is completely concerned with WW. SpringMVC might be another option, since it has probably the most natural integration with Acegi. There is a certain amount of overlap between Spring and Plexus that we'd probably have to map with a custom Spring container or something, but that's likely to be everywhere, since dependency injection is such a hot topic (and very useful). What do you all think? -john
[jira] Commented: (CONTINUUM-69) Make sure /webapp only contains web resources and not classes.
[ http://jira.codehaus.org/browse/CONTINUUM-69?page=comments#action_52311 ] John Casey commented on CONTINUUM-69: - thanks. I wanted to make sure it was on the radar, and figure out where it belongs. Make sure /webapp only contains web resources and not classes. -- Key: CONTINUUM-69 URL: http://jira.codehaus.org/browse/CONTINUUM-69 Project: Continuum Type: Task Versions: 1.0-alpha-3 Reporter: Trygve Laugstol Assignee: Trygve Laugstol Fix For: 1.1 We'll need to deal with this next version, it's not critical in any way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-352) scm value is erratic
[ http://jira.codehaus.org/browse/CONTINUUM-352?page=all ] John Casey updated CONTINUUM-352: - Description: Introduction: I maven1 project that have inaccurate information in scm commection (since it wasn't used then) Problem I uploaded the project.xml and edited online the scm url all way down from there, the value seemed to be resetted (is it possible that the scm url is taken from the new project.xml? in that case, why bother in editing if it will be replaced by cvs location?) I managed to compile the project one (manual trigger, but errors due to cvs connection keep appearing (probably due to the scm url beeing modified on project update) MO: the information supplied on the webapp shuold always override the provided by the sources, If it is a matter of documentation (it shuold certainly be well clarified) the scm url is the one found in project.xml. It shuold specially be weel informed (visually on the web) that the scm url will be overwritten by the value of the one in project.xm, if that is the actual behaviour. PS: great pice of software was: Introduction: I maven1 project that have inaccurate information in scm commection (since it wasn't used then) Problem I uploaded the project.xml and edited online the scm url all way down from there, the value seemed to be resetted (is it possible that the scm url is taken from the new project.xml? in that case, why bother in editing if it will be replaced by cvs location?) I managed to compile the project one (manual trigger, but errors due to cvs connection keep appearing (probably due to the scm url beeing modified on project update) MO: the information supplied on the webapp shuold always override the provided by the sources, If it is a matter of documentation (it shuold certainly be well clarified) the scm url is the one found in project.xml. It shuold specially be weel informed (visually on the web) that the scm url will be overwritten by the value of the one in project.xm, if that is the actual behaviour. PS: great pice of software Fix Version: 1.0.2 Environment: scm value is erratic Key: CONTINUUM-352 URL: http://jira.codehaus.org/browse/CONTINUUM-352 Project: Continuum Type: Bug Components: Web interface Versions: 1.0-beta-1 Reporter: Miguel Griffa Priority: Blocker Fix For: 1.0.2 Introduction: I maven1 project that have inaccurate information in scm commection (since it wasn't used then) Problem I uploaded the project.xml and edited online the scm url all way down from there, the value seemed to be resetted (is it possible that the scm url is taken from the new project.xml? in that case, why bother in editing if it will be replaced by cvs location?) I managed to compile the project one (manual trigger, but errors due to cvs connection keep appearing (probably due to the scm url beeing modified on project update) MO: the information supplied on the webapp shuold always override the provided by the sources, If it is a matter of documentation (it shuold certainly be well clarified) the scm url is the one found in project.xml. It shuold specially be weel informed (visually on the web) that the scm url will be overwritten by the value of the one in project.xm, if that is the actual behaviour. PS: great pice of software -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-410) Assigning a runAs user in the rc script yields directory does not exist error.
[ http://jira.codehaus.org/browse/CONTINUUM-410?page=all ] John Casey updated CONTINUUM-410: - Description: Created a symlink to the linux run.sh script in init.d. Change the runAs to a defined user named continuum On attempts to run the server, I receive a directory does not exist error at the su -m continuum command. I'll attach the exact debug when I have the machine available. was: Created a symlink to the linux run.sh script in init.d. Change the runAs to a defined user named continuum On attempts to run the server, I receive a directory does not exist error at the su -m continuum command. I'll attach the exact debug when I have the machine available. Fix Version: 1.0.2 is this the best approach to starting continuum up on a gentoo box at boot-time? what about the javaservicewrapper stuff?? Assigning a runAs user in the rc script yields directory does not exist error. Key: CONTINUUM-410 URL: http://jira.codehaus.org/browse/CONTINUUM-410 Project: Continuum Type: Bug Versions: 1.0-beta-1 Environment: gentoo linux Reporter: Corridor Software Developer Priority: Critical Fix For: 1.0.2 Created a symlink to the linux run.sh script in init.d. Change the runAs to a defined user named continuum On attempts to run the server, I receive a directory does not exist error at the su -m continuum command. I'll attach the exact debug when I have the machine available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-37) Add a professional user interface
[ http://jira.codehaus.org/browse/CONTINUUM-37?page=all ] John Casey updated CONTINUUM-37: Description: I'd like to see a professional interface with some flash components like a Macromedia Flex interface. Laszlo provides an open source implementation of this technology (CPL License). http://www.laszlosystems.com/ You can see some demo here (http://www.laszlosystems.com/demos/). The screen creation is very simple, it a very simple xml. I'll hope you'll be interesting. was: I'd like to see a professional interface with some flash components like a Macromedia Flex interface. Laszlo provides an open source implementation of this technology (CPL License). http://www.laszlosystems.com/ You can see some demo here (http://www.laszlosystems.com/demos/). The screen creation is very simple, it a very simple xml. I'll hope you'll be interesting. Fix Version: 1.1 Environment: Add a professional user interface - Key: CONTINUUM-37 URL: http://jira.codehaus.org/browse/CONTINUUM-37 Project: Continuum Type: New Feature Components: Web interface Reporter: Emmanuel Venisse Fix For: 1.1 I'd like to see a professional interface with some flash components like a Macromedia Flex interface. Laszlo provides an open source implementation of this technology (CPL License). http://www.laszlosystems.com/ You can see some demo here (http://www.laszlosystems.com/demos/). The screen creation is very simple, it a very simple xml. I'll hope you'll be interesting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-58) Build all dependent projects.
[ http://jira.codehaus.org/browse/CONTINUUM-58?page=all ] John Casey updated CONTINUUM-58: Fix Version: 1.1 Environment: Build all dependent projects. - Key: CONTINUUM-58 URL: http://jira.codehaus.org/browse/CONTINUUM-58 Project: Continuum Type: New Feature Reporter: Trygve Laugstol Fix For: 1.1 When building foo-core, foo-web and foo-xml-rpc should be built aswell to make sure that any changes to the core didn't break anything downstream. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-256) trace memory leak with yourkit
[ http://jira.codehaus.org/browse/CONTINUUM-256?page=all ] John Casey updated CONTINUUM-256: - Fix Version: 1.1 Environment: is this still a problem? trace memory leak with yourkit -- Key: CONTINUUM-256 URL: http://jira.codehaus.org/browse/CONTINUUM-256 Project: Continuum Type: Bug Components: Core system Reporter: Brett Porter Fix For: 1.1 continuum has been spitting OOME in our test environment -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-427) create an XML report of all the failures in all the builds
[ http://jira.codehaus.org/browse/CONTINUUM-427?page=all ] John Casey updated CONTINUUM-427: - Priority: Major (was: Critical) Fix Version: 1.1 create an XML report of all the failures in all the builds -- Key: CONTINUUM-427 URL: http://jira.codehaus.org/browse/CONTINUUM-427 Project: Continuum Type: New Feature Components: Web interface Reporter: james strachan Fix For: 1.1 It'd make it really easy to slice and dice the data make custom views/portlets/pages across multiple continuum installations on different hardware, OS and JVM if we could get a single XML report of all the failures in all the builds as a blob of XML. e.g. results project id=ActiveMQ failuretestcaseorg.activemq.FooTest/testcaseresultURLhttp://acme.com/foo.txt/resultURL/failure /project project id=ServiceMix !-- no failures -- /project /results Then with a trivial bit of XSLT (or some script) we can easily slice and dice the results from multiple continuum installations (OS, hardware, JVM) into reports to make it easy to see the big picture. Hopefully these reports can also become part of CI - but at least folks can then hack up their own to get going. e.g. folks could emded on wiki/portal pages summaries of whats working not etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-232) Build when a dependency has been changed/updated
[ http://jira.codehaus.org/browse/CONTINUUM-232?page=all ] John Casey updated CONTINUUM-232: - Description: Fix Version: 1.1 Environment: Build when a dependency has been changed/updated Key: CONTINUUM-232 URL: http://jira.codehaus.org/browse/CONTINUUM-232 Project: Continuum Type: New Feature Components: Core system Reporter: Trygve Laugstol Fix For: 1.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
