[jira] Created: (CONTINUUM-209) Update to the latest Maven SCM code
Update to the latest Maven SCM code --- Key: CONTINUUM-209 URL: http://jira.codehaus.org/browse/CONTINUUM-209 Project: Continuum Type: Task Reporter: Jason van Zyl Assigned to: Trygve Laugstol The latest Maven SCM code is required for the blame mechanism. -- 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] Created: (CONTINUUM-210) Use the new slimdog mojo for web testing
Use the new slimdog mojo for web testing Key: CONTINUUM-210 URL: http://jira.codehaus.org/browse/CONTINUUM-210 Project: Continuum Type: Task Reporter: Jason van Zyl Fix For: 1.0-beta-1 Thanks to John we can use a mojo. -- 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-210) Use the new slimdog mojo for web testing
[ http://jira.codehaus.org/browse/CONTINUUM-210?page=all ] Jason van Zyl updated CONTINUUM-210: Assign To: Emmanuel Venisse Fix Version: 1.0-beta-1 Use the new slimdog mojo for web testing Key: CONTINUUM-210 URL: http://jira.codehaus.org/browse/CONTINUUM-210 Project: Continuum Type: Task Reporter: Jason van Zyl Assignee: Emmanuel Venisse Fix For: 1.0-beta-1 Thanks to John we can use a mojo. -- 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] Assigned: (CONTINUUM-206) Document the use of Continuum behind Apache using mod_proxy
[ http://jira.codehaus.org/browse/CONTINUUM-206?page=all ] Trygve Laugstol reassigned CONTINUUM-206: - Assign To: Trygve Laugstol Document the use of Continuum behind Apache using mod_proxy --- Key: CONTINUUM-206 URL: http://jira.codehaus.org/browse/CONTINUUM-206 Project: Continuum Type: Task Reporter: Jason van Zyl Assignee: Trygve Laugstol Fix For: 1.0-alpha-3 Write a simple APT document for those wishing to use Continuum with Apache. -- 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] Closed: (CONTINUUM-206) Document the use of Continuum behind Apache using mod_proxy
[ http://jira.codehaus.org/browse/CONTINUUM-206?page=all ] Trygve Laugstol closed CONTINUUM-206: - Resolution: Fixed Document the use of Continuum behind Apache using mod_proxy --- Key: CONTINUUM-206 URL: http://jira.codehaus.org/browse/CONTINUUM-206 Project: Continuum Type: Task Reporter: Jason van Zyl Assignee: Trygve Laugstol Fix For: 1.0-alpha-3 Write a simple APT document for those wishing to use Continuum with Apache. -- 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] Assigned: (CONTINUUM-201) Convert IT tests to Java
[ http://jira.codehaus.org/browse/CONTINUUM-201?page=all ] Jason van Zyl reassigned CONTINUUM-201: --- Assign To: Trygve Laugstol Convert IT tests to Java Key: CONTINUUM-201 URL: http://jira.codehaus.org/browse/CONTINUUM-201 Project: Continuum Type: Task Reporter: Jason van Zyl Assignee: Trygve Laugstol Fix For: 1.0-beta-1 They python scripts are proving cumbersome and will probably make it hard for most java developers to dig in. -- 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] Assigned: (CONTINUUM-171) exception in failed checkout is not helpful
[ http://jira.codehaus.org/browse/CONTINUUM-171?page=all ] Jason van Zyl reassigned CONTINUUM-171: --- Assign To: Trygve Laugstol exception in failed checkout is not helpful --- Key: CONTINUUM-171 URL: http://jira.codehaus.org/browse/CONTINUUM-171 Project: Continuum Type: Bug Reporter: Brett Porter Assignee: Trygve Laugstol Fix For: 1.0-beta-1 the exception propogated for a failed checkout doesn't report what actually went wrong (in my case, it attempted to use a directory 1 which was left over from before I had blown away the db, but already existed). -- 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] Closed: (CONTINUUM-200) Employ cascading delete for project builds
[ http://jira.codehaus.org/browse/CONTINUUM-200?page=all ] Jason van Zyl closed CONTINUUM-200: --- Resolution: Fixed This is now working. Employ cascading delete for project builds -- Key: CONTINUUM-200 URL: http://jira.codehaus.org/browse/CONTINUUM-200 Project: Continuum Type: Improvement Reporter: Jason van Zyl Fix For: 1.0-beta-1 The method of deleting builds from a project is cumbersome. Any reason we're not using the cascading delete features in JPOX? -- 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] Assigned: (CONTINUUM-183) Should be able to build without using SCM.
[ http://jira.codehaus.org/browse/CONTINUUM-183?page=all ] Jason van Zyl reassigned CONTINUUM-183: --- Assign To: Trygve Laugstol Trygve, you seem to have a plan for this, maybe you can work with Simon to get this going. Should be able to build without using SCM. -- Key: CONTINUUM-183 URL: http://jira.codehaus.org/browse/CONTINUUM-183 Project: Continuum Type: Wish Components: continuum-core Versions: 1.0-alpha-2 Environment: x86 Windows NT 4.0 j2sdk1.4.2_05 maven 1.0.2 Reporter: Simon Richardson Assignee: Trygve Laugstol Priority: Blocker Fix For: 1.0-beta-1 The scm module does not support our version control system and I wondered if there was a way to circumvent the scm aspect of continuum so that it only builds what is on the file system? -- 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] Created: (CONTINUUM-212) Add StarTeam provider to Continuum
Add StarTeam provider to Continuum -- Key: CONTINUUM-212 URL: http://jira.codehaus.org/browse/CONTINUUM-212 Project: Continuum Type: New Feature Reporter: Jason van Zyl Assigned to: Emmanuel Venisse Fix For: 1.0-beta-1 Emmanuel, could work with Dan Tran to try and integrate StarTeam into Continuum? -- 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] Assigned: (CONTINUUM-208) If an SCM command fails it would be useful to see the command that caused the failure
[ http://jira.codehaus.org/browse/CONTINUUM-208?page=all ] Jason van Zyl reassigned CONTINUUM-208: --- Assign To: Trygve Laugstol If an SCM command fails it would be useful to see the command that caused the failure - Key: CONTINUUM-208 URL: http://jira.codehaus.org/browse/CONTINUUM-208 Project: Continuum Type: Improvement Reporter: Jason van Zyl Assignee: Trygve Laugstol Fix For: 1.0-beta-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
[jira] Assigned: (CONTINUUM-137) Store dependency information at the ContinuumProject level
[ http://jira.codehaus.org/browse/CONTINUUM-137?page=all ] Jason van Zyl reassigned CONTINUUM-137: --- Assign To: Jason van Zyl Store dependency information at the ContinuumProject level -- Key: CONTINUUM-137 URL: http://jira.codehaus.org/browse/CONTINUUM-137 Project: Continuum Type: New Feature Versions: 1.0-alpha-3 Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 1.0-beta-1 In order to be able to build in any deterministic order we need dependency information on all the projects entered into the system. -- 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] Commented: (CONTINUUM-204) Add SOAP interface using xfire
[ http://jira.codehaus.org/browse/CONTINUUM-204?page=comments#action_42601 ] Dan Diephouse commented on CONTINUUM-204: - It works, I've tested it from .NET and Java, and I dare say its useful :-). I have some docs checked into cvs as well. A couple things to do yet: * Validate the SCM URLS (I took an initial look and couldn't figure out how to do this) * Possibly create a SOAP api to change the notifiers used on a Project? Add SOAP interface using xfire -- Key: CONTINUUM-204 URL: http://jira.codehaus.org/browse/CONTINUUM-204 Project: Continuum Type: New Feature Reporter: Jason van Zyl Assignee: Dan Diephouse Fix For: 1.0-beta-1 Dan will be taking care of this. -- 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] Commented: (CONTINUUM-204) Add SOAP interface using xfire
[ http://jira.codehaus.org/browse/CONTINUUM-204?page=comments#action_42602 ] Dan Diephouse commented on CONTINUUM-204: - Also, once security is integrated we will have to change the API to take username/passwords as well Add SOAP interface using xfire -- Key: CONTINUUM-204 URL: http://jira.codehaus.org/browse/CONTINUUM-204 Project: Continuum Type: New Feature Reporter: Jason van Zyl Assignee: Dan Diephouse Fix For: 1.0-beta-1 Dan will be taking care of this. -- 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] Created: (CONTINUUM-213) Mail sender needs to be able to deal with authorization on the server
Mail sender needs to be able to deal with authorization on the server - Key: CONTINUUM-213 URL: http://jira.codehaus.org/browse/CONTINUUM-213 Project: Continuum Type: New Feature Reporter: Jason van Zyl Assigned to: Emmanuel Venisse Fix For: 1.0-beta-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
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/09-Jul-2005_04.00.24/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-1644) Running Maven in a directory not containing a POM file always results in 'Build Successful'.
Running Maven in a directory not containing a POM file always results in 'Build Successful'. Key: MAVEN-1644 URL: http://jira.codehaus.org/browse/MAVEN-1644 Project: maven Type: Improvement Components: core Versions: 1.0.2, 1.1-beta-1 Environment: Not of importance. Reporter: Davy Toch Priority: Minor Fix For: 1.1-beta-2 In maven 1.0.2 and 1.1-beta-1, running 'maven' in a directory that doesn't contain a POM file always results in 'Build Succesful'. == $.\maven.bat __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-1 BUILD SUCCESSFUL Total time : 1 seconds Finished at : vrijdag 8 juli 2005 13:32:35 CEST == This could be confusing for novice users of Maven and it would be better to generate an error stating that no POM file was found. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/09-Jul-2005_08.00.22/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: POM issues in the repository
There is nothing wrong with having or using the minimal POMs that can be found in the repository. As a user if I find, for example, a sun library for which no POM exists, I am willing to submit a basic POM which will cause my build to continue unimpeded by its absence. I won't however, stop every time this occurs and fill out a bunch of excess metadata with no programmatic relevance that someone else decided would be nice to have in the file as well. Keep in mind this one file format is used for two entirely distinct purposes. The first, describing a project you're building, seems a more plausible explanation of what the extra metadata is geared towards. The second, using the project as a dependency, gains no benefit from the metadata you are suggesting users should insist on. When the m2 codebase becomes beta-ready and the minimal information in the repository lets me build my projects, I personally don't want to wait around for a metadata cleanup before they open the doors on mainstream usage. I'd rather have the extra effort go towards plugin development. But since maven permits you to specify your repository in your settings, none of this is a problem. If you need a higher quality repository than what's available you can simply create one within your own environment and point to it. Each time you need a new dependency met, you can copy from ibiblio and add the additional information to the POM necessary for your projects. See maven-proxy, it works with m2 as well. Kris On Fri, 2005-07-08 at 09:53 +0200, Maczka Michal wrote: If I can have a suggestion: I the fact that repository is changing constantly is even worst then the fact that some POMs are missing or are incorrect. I cannot imagine somebody using m2 in production and relaying on such unstable repository which introduces indeterminism to builds. It's just enough to change an order of dependencies in one of the POMs and some builds might be broken or what's very serious not possible to reproduce in the future. From this perspective it might be better to have a smaller but high quality repository which is growing then a big crappy repository containing invalid POMs or naked POMs like that (http://www.ibiblio.org/maven2/axis/axis/1.2/axis-1.2.pom): project modelVersion4.0.0/modelVersion groupIdaxis/groupId artifactIdaxis/artifactId version1.2/version /project IMO at least project description and license should be present in all POMs in the repository. It will be nice to have more things in those POMs (e.g. url of the main website, organization section etc) And unfortunately no tool can provide this information automatically. You need many people to help you with that! Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POM issues in the repository
What about taking a play from the Gentoo Portage book? Something similar to the package masking ~arch keyword might do the trick: Add an extra tag to the POM schema which indicates whether or not the POM is stable. Add a tag in the settings file which indicates whether or not you want to use unstable dependencies. Modify the dependency download code to fail on unstable downloads unless the settings file indicates otherwise. This way, you can use the same repository for both camps of users. Thoughts? Kris On Sat, 2005-07-09 at 00:39 -0700, Michal Maczka wrote: John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think that such a drastic step will only serve to completely marginalize maven 2.x, and alienate users. Who would convert to using m2 if they first had to re-request uploads for the 10 dependencies they have?? I hope that m2 users will help you to get this problem fixed. While I agree that the repository information we currently have is inadequate and incomplete, such is life. When have you ever worked on a product revision/rewrite where you *didn't* have to deal with bad data? In my build system?? Never! That's too high risk to take. I would only change the build system if I would be certain that if will not deceive me as I have to many problems to deal with elsewhere. The answer is *never* to blow away everything you know and replace it with only the things you know to a perfect degree...you'd be re-creating your datastore with every new major version. Also, to address your assertion about Maven 2.x's readiness for production - perhaps you noticed the -alpha-3 notation we've used on the latest release? ;) This software isn't perfect yet, and neither is the data it relies on...but we're working on it, and it *will* get better. But you are aiming at 2.0 release real soon: in August, do not you? I personally would keep maven in alpha stage as long as repository is not ready for public use even if the m2 code will be prefect and ready for prime time as you simply cannot use m2 without reliable repository. This gives a full right to use the current strategy for improving the repository data. Obviously, having naked poms isn't a good idea, but it will help users trying to migrate from maven 1.x (where they couldn't use the transitivity of dependencies anyway), and as these users attempt to trim their own dep lists, they can help us fix these bad poms. We cannot adopt the strategy of only putting perfect metadata into the repository, since our users need access to such a wide spectrum of libraries. Initially, for upgrading users, it will be better to have *some* access to these artifacts rather than clogging the MAVENUPLOAD project with re-requests. I am complete agreeing with you. I am just linking 2.0 release (which gives clear signal to users: __it is production ready__) with readiness of the repository for the demanding (normal?) users and not just for those brave early adopters, which are generally fans of maven and will use it anyway. Once m2 final relases will get the label of being not reliable as its repository is constantly changing this is what can be actually the factor (just hypothesis) which marginalize maven 2.x, and alienate users as it is very difficult to change such negative image after bad press, which you will surly have. I am just feeling that missisng poms in the repository give more motivation to provide good ones then naked ones as they give the false impression that data in the repository is OK. I do hope to have time to help you to clean you poms I am using. And I am hoping that your community will really help you to get it fixed asap. just my 2 cents regards Michal -- Zamachy w Londynie: FOTO RAPORT http://link.interia.pl/f18a1 - 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]
[jira] Assigned: (CONTINUUM-177) Include samples of configuration elements in the documenteation
[ http://jira.codehaus.org/browse/CONTINUUM-177?page=all ] Jason van Zyl reassigned CONTINUUM-177: --- Assign To: Trygve Laugstol Include samples of configuration elements in the documenteation --- Key: CONTINUUM-177 URL: http://jira.codehaus.org/browse/CONTINUUM-177 Project: Continuum Type: Improvement Components: continuum-site Reporter: Trygve Laugstol Assignee: Trygve Laugstol Fix For: 1.0-alpha-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-46) view the build schedule
[ http://jira.codehaus.org/browse/CONTINUUM-46?page=all ] Jason van Zyl updated CONTINUUM-46: --- Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 view the build schedule --- Key: CONTINUUM-46 URL: http://jira.codehaus.org/browse/CONTINUUM-46 Project: Continuum Type: New Feature Reporter: Brett Porter Priority: Minor Fix For: 1.0-beta-1 it would be good to be able to display an overall view of the build schedule so you can see what builds are coming up, or just done. -- 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-43) multiple schedules and schedule selection
[ http://jira.codehaus.org/browse/CONTINUUM-43?page=all ] Jason van Zyl updated CONTINUUM-43: --- Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 multiple schedules and schedule selection - Key: CONTINUUM-43 URL: http://jira.codehaus.org/browse/CONTINUUM-43 Project: Continuum Type: New Feature Reporter: Brett Porter Fix For: 1.0-beta-1 it would be good to be able to add new schedules and be able to select them on a per project or per group basis. Some projects would like to be able to build much more frequently as they have frequent changes. -- 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-93) setup a public demo site
[ http://jira.codehaus.org/browse/CONTINUUM-93?page=all ] Jason van Zyl updated CONTINUUM-93: --- Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 setup a public demo site Key: CONTINUUM-93 URL: http://jira.codehaus.org/browse/CONTINUUM-93 Project: Continuum Type: Task Versions: 1.0-alpha-3 Reporter: Brett Porter Assignee: Jason van Zyl Fix For: 1.0-beta-1 we need to get a public demo site up, with security, running on port 80. It might be possible to do this apache, but if not we could use our own machine -- 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-69) Make sure /webapp only contains web resources and not classes.
[ http://jira.codehaus.org/browse/CONTINUUM-69?page=all ] Jason van Zyl updated CONTINUUM-69: --- Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 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.0-beta-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-143) We need to categorize error states and display them useful messages to the user
[ http://jira.codehaus.org/browse/CONTINUUM-143?page=all ] Jason van Zyl updated CONTINUUM-143: Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 We need to categorize error states and display them useful messages to the user --- Key: CONTINUUM-143 URL: http://jira.codehaus.org/browse/CONTINUUM-143 Project: Continuum Type: Improvement Versions: 1.0-alpha-3 Reporter: Jason van Zyl Fix For: 1.0-beta-1 Right now we're only tracking checkout errors but we need to categorize all error so that we can easily extract them and display useful messages to the user. -- 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-137) Store dependency information at the ContinuumProject level
[ http://jira.codehaus.org/browse/CONTINUUM-137?page=all ] Jason van Zyl updated CONTINUUM-137: Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 Store dependency information at the ContinuumProject level -- Key: CONTINUUM-137 URL: http://jira.codehaus.org/browse/CONTINUUM-137 Project: Continuum Type: New Feature Versions: 1.0-alpha-3 Reporter: Jason van Zyl Fix For: 1.0-beta-1 In order to be able to build in any deterministic order we need dependency information on all the projects entered into the system. -- 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-39) build in the correct order
[ http://jira.codehaus.org/browse/CONTINUUM-39?page=all ] Jason van Zyl updated CONTINUUM-39: --- Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 build in the correct order -- Key: CONTINUUM-39 URL: http://jira.codehaus.org/browse/CONTINUUM-39 Project: Continuum Type: Improvement Versions: 1.0-alpha-3 Reporter: Brett Porter Assignee: Trygve Laugstol Priority: Critical Fix For: 1.0-beta-1 I'm unsure if this is already the case - it didn't appear to be. If a project is going to depend on the output of another scheduled continuum build (ie dependency id including version matches that of the other project's id), then they should be built in the correct order, as in the reactor. -- 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-44) multiple profiles
[ http://jira.codehaus.org/browse/CONTINUUM-44?page=all ] Jason van Zyl updated CONTINUUM-44: --- Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 multiple profiles - Key: CONTINUUM-44 URL: http://jira.codehaus.org/browse/CONTINUUM-44 Project: Continuum Type: New Feature Reporter: Brett Porter Fix For: 1.0-beta-1 would like to be able to define a profile (which can include certain environmental things such as the version of m2 to use, the JDK version, etc). Profiles should be able to be used globally, per group or per project. In this way, you could build certain projects under a variety of different JDKs for example. -- 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-127) Try using a series of incorrect data in the integration tests
[ http://jira.codehaus.org/browse/CONTINUUM-127?page=all ] Jason van Zyl updated CONTINUUM-127: Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 Try using a series of incorrect data in the integration tests - Key: CONTINUUM-127 URL: http://jira.codehaus.org/browse/CONTINUUM-127 Project: Continuum Type: Task Versions: 1.0-alpha-3 Reporter: Jason van Zyl Assignee: Trygve Laugstol Priority: Critical Fix For: 1.0-beta-1 We need to trap any incorrect data being thrown at continuum coming from any interface. The best place to try this is the integration tests that we run from python. I accidentally used some bad POMs using the xmlrpc interface and in the web interface the projects seems to stay perpetually in the Checking Out state. -- 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-125) Export/Import projects, configuration and history
[ http://jira.codehaus.org/browse/CONTINUUM-125?page=all ] Jason van Zyl updated CONTINUUM-125: Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 Export/Import projects, configuration and history - Key: CONTINUUM-125 URL: http://jira.codehaus.org/browse/CONTINUUM-125 Project: Continuum Type: Task Components: continuum-core, continuum-xmlrpc Reporter: Trygve Laugstol Fix For: 1.0-beta-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
[jira] Updated: (CONTINUUM-139) Design per project configuration
[ http://jira.codehaus.org/browse/CONTINUUM-139?page=all ] Jason van Zyl updated CONTINUUM-139: Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 Design per project configuration Key: CONTINUUM-139 URL: http://jira.codehaus.org/browse/CONTINUUM-139 Project: Continuum Type: Task Versions: 1.0-alpha-3 Reporter: Jason van Zyl Fix For: 1.0-beta-1 We need to design the per project configuration and figure out how to display this in the web UI. -- 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-145) Allow the creation of template project configurations
[ http://jira.codehaus.org/browse/CONTINUUM-145?page=all ] Jason van Zyl updated CONTINUUM-145: Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 Allow the creation of template project configurations - Key: CONTINUUM-145 URL: http://jira.codehaus.org/browse/CONTINUUM-145 Project: Continuum Type: New Feature Reporter: Jason van Zyl Fix For: 1.0-beta-1 For a given project type, say m2, allow the user the define template values that will be used when new projects of that type are created. -- 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-117) Blame mechanism
[ http://jira.codehaus.org/browse/CONTINUUM-117?page=all ] Jason van Zyl updated CONTINUUM-117: Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 Blame mechanism --- Key: CONTINUUM-117 URL: http://jira.codehaus.org/browse/CONTINUUM-117 Project: Continuum Type: New Feature Versions: 1.0-alpha-3 Reporter: Jason van Zyl Fix For: 1.0-beta-1 When a build breaks we need to be able to look at the ID(s) in the last set of changes that broke a build so that we can track and notify. -- 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-156) should validate that an updated pom doesn't change too drastically
[ http://jira.codehaus.org/browse/CONTINUUM-156?page=all ] Jason van Zyl updated CONTINUUM-156: Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 should validate that an updated pom doesn't change too drastically -- Key: CONTINUUM-156 URL: http://jira.codehaus.org/browse/CONTINUUM-156 Project: Continuum Type: Improvement Reporter: Brett Porter Fix For: 1.0-beta-1 I added maven-core's POM, which is using a post -alpha-2 technique of inheriting the SCM connection URL and appending the artifact ID. This resulted in the new SCM URL being different and so it checked out the root POM and proceeded to checkout all of maven/components/trunk. IF the group ID/artifact ID of the POM changes on update, I think this needs to go into an error state that requires user intervention to either accept it has changed, or find out what is wrong. -- 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-30) Project grouping features
[ http://jira.codehaus.org/browse/CONTINUUM-30?page=all ] Jason van Zyl updated CONTINUUM-30: --- Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 Project grouping features - Key: CONTINUUM-30 URL: http://jira.codehaus.org/browse/CONTINUUM-30 Project: Continuum Type: New Feature Versions: 1.0-alpha-3 Reporter: Jason van Zyl Fix For: 1.0-beta-1 It would be nice to start incorporating some functionality based on groupIds. Sorting by groupId, or a separate page for projects with the same groupId, or reports for a whole groupId. Say a summary failure report with links to details instead of 10 different emails. -- 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-6) Add security
[ http://jira.codehaus.org/browse/CONTINUUM-6?page=all ] Jason van Zyl updated CONTINUUM-6: -- Fix Version: (was: 1.0-alpha-3) 1.0-beta-1 Add security Key: CONTINUUM-6 URL: http://jira.codehaus.org/browse/CONTINUUM-6 Project: Continuum Type: New Feature Components: continuum-web Versions: 1.0-alpha-3 Reporter: Trygve Laugstol Assignee: Jason van Zyl Fix For: 1.0-beta-1 Add a security scheme for the web interface. Possible permissions: * Add project * Edit project * Remove project * Enqueue project for building -- 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: POM issues in the repository
-Original Message- From: Kris Bravo [mailto:[EMAIL PROTECTED] Sent: Saturday, July 09, 2005 5:18 PM To: Maven Developers List Subject: RE: POM issues in the repository There is nothing wrong with having or using the minimal POMs that can be found in the repository. As a user if I find, for example, a sun library for which no POM exists, I am willing to submit a basic POM which will cause my build to continue unimpeded by its absence. I won't however, stop every time this occurs and fill out a bunch of excess metadata with no programmatic relevance that someone else decided would be nice to have in the file as well. Keep in mind this one file format is used for two entirely distinct purposes. The first, describing a project you're building, seems a more plausible explanation of what the extra metadata is geared towards. The second, using the project as a dependency, gains no benefit from the metadata you are suggesting users should insist on. When the m2 codebase becomes beta-ready and the minimal information in the repository lets me build my projects, I personally don't want to wait around for a metadata cleanup before they open the doors on mainstream usage. I'd rather have the extra effort go towards plugin development. But since maven permits you to specify your repository in your settings, none of this is a problem. If you need a higher quality repository than what's available you can simply create one within your own environment and point to it. Each time you need a new dependency met, you can copy from ibiblio and add the additional information to the POM necessary for your projects. See maven-proxy, it works with m2 as well. Kris You didn't get my point. My point was that it is irrelevant if POMs in the repository are minimal or not. But it is extremely important that information which is the main maven repository is _not changing_!!! Otherwise: a) build won't be reproductable b) the scenario which you are proposing - everybody maintaining its own maven repository with competing metadata even for open source projects will become the reality. And this is something which in my opinion won't be any good for maven nor for improving the quality of the maven central repository. I already know some people which are creating their own m2 repositories and the work which there are doing is not at all serving maven community. I am all for centralising that effort. Note then when I am saying that no POMs should not be changed - this means that no dependency should be added, removed or moved to different position witin the pom. The algorithm which resolves transitive dependencies is very fragile: it is even (accordingly to my knowledge) sensitive to the position of the dependency in the pom. I also have no better alternative to what's happening now with m2 repository. But I share Vincent's opinion: There needs to be a big effort to clean the m2 repo of bad POMs and I am just adding that this in my opinion should happen and ___finish_ before maven 2.0 will be proclaimed as final or even beta. Otherwise the situation which happen with m1: some people tried unstable beta versions and never come back to maven will be repeated one more time. But this time it won't happen due to the code quality (which is really excellent in case of m2) but due to the repository related problems. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/09-Jul-2005_12.00.24/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: POM issues in the repository
You didn't get my point. My point was that it is irrelevant if POMs in the repository are minimal or not. But it is extremely important that information which is the main maven repository is _not changing_!!! I did get your overall point. But contrary to what you're now saying, you went on this tangent, which I was addressing specifically: From this perspective it might be better to have a smaller but high quality repository which is growing then a big crappy repository containing invalid POMs or naked POMs like that (http://www.ibiblio.org/maven2/axis/axis/1.2/axis-1.2.pom): project modelVersion4.0.0/modelVersion groupIdaxis/groupId artifactIdaxis/artifactId version1.2/version /project IMO at least project description and license should be present in all POMs in the repository. So if you're now saying that minimal POMs are okay, then yeah, I agree. Kris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-563) Add generation of application.xml in EAR plugin
Add generation of application.xml in EAR plugin --- Key: MNG-563 URL: http://jira.codehaus.org/browse/MNG-563 Project: Maven 2 Type: New Feature Components: maven-plugins Versions: 2.0-alpha-3 Reporter: Vincent Massol It sems the current version in SVN trunk does not support generating the application.xml file. It does support adding EAR modules though. Generating application.xml would allow not having to hardcode the modules nor the version in the application.xml file. For example: ?xml version=1.0 encoding=UTF-8? !DOCTYPE application PUBLIC -//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN http://java.sun.com/j2ee/dtds/application_1_2.dtd; application display-nameSimple EAR for testing/display-name module web web-urisimple-war-0.6-SNAPSHOT.war/web-uri context-root/simpleweb/context-root /web /module /application -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-215) Integrate and test the MSN notifier
Integrate and test the MSN notifier --- Key: CONTINUUM-215 URL: http://jira.codehaus.org/browse/CONTINUUM-215 Project: Continuum Type: Task Reporter: Jason van Zyl Assigned to: Emmanuel Venisse Fix For: 1.0-beta-1 The test m2 projects can be modified to use an MSN notifier so that no changes to the web interface are required for testing. -- 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] Commented: (MNG-563) Add generation of application.xml in EAR plugin
[ http://jira.codehaus.org/browse/MNG-563?page=comments#action_42604 ] Stephane Nicoll commented on MNG-563: - Following a chat on IRC: It's done for 1.3 and 1.4 (no 1.2 though). use ear:genearte-application-xml Add generation of application.xml in EAR plugin --- Key: MNG-563 URL: http://jira.codehaus.org/browse/MNG-563 Project: Maven 2 Type: New Feature Components: maven-plugins Versions: 2.0-alpha-3 Reporter: Vincent Massol It sems the current version in SVN trunk does not support generating the application.xml file. It does support adding EAR modules though. Generating application.xml would allow not having to hardcode the modules nor the version in the application.xml file. For example: ?xml version=1.0 encoding=UTF-8? !DOCTYPE application PUBLIC -//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN http://java.sun.com/j2ee/dtds/application_1_2.dtd; application display-nameSimple EAR for testing/display-name module web web-urisimple-war-0.6-SNAPSHOT.war/web-uri context-root/simpleweb/context-root /web /module /application -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POM issues in the repository
Kris Bravo wrote: You didn't get my point. My point was that it is irrelevant if POMs in the repository are minimal or not. But it is extremely important that information which is the main maven repository is _not changing_!!! I did get your overall point. But contrary to what you're now saying, you went on this tangent, which I was addressing specifically: From this perspective it might be better to have a smaller but high quality repository which is growing then a big crappy repository containing invalid POMs or naked POMs like that (http://www.ibiblio.org/maven2/axis/axis/1.2/axis-1.2.pom): project modelVersion4.0.0/modelVersion groupIdaxis/groupId artifactIdaxis/artifactId version1.2/version /project IMO at least project description and license should be present in all POMs in the repository. So if you're now saying that minimal POMs are okay, then yeah, I agree. Kris To make myself clear - I wanted to say that: a) maven _central_ repository to be reliable should implement WORM (Write Once Read Many times) principle from some moment in time. It would be nice to know a date when it will happen to be sure that poms in the central repository are not going to change even a bit. IMO it this date should preceded 2.0 release but it is definitely too early to make that move now as the velocity of repository building will go down. b) if WORM principle would be applied - then naked poms still may exist in the central repository but it will be a big pity to have them threre as they never can be changed or improved. That's why it would be actually better to get rid of them at some moment in time as the place for high quality poms will remain open. Michal -- Najnowsze wiadomosci!!! http://link.interia.pl/f18a0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-563) Add generation of application.xml in EAR plugin
[ http://jira.codehaus.org/browse/MNG-563?page=comments#action_42605 ] Vincent Massol commented on MNG-563: Cool. The next step would be to bind the generation to a phase (generate-sources?) so that running m2 install will run it. Add generation of application.xml in EAR plugin --- Key: MNG-563 URL: http://jira.codehaus.org/browse/MNG-563 Project: Maven 2 Type: New Feature Components: maven-plugins Versions: 2.0-alpha-3 Reporter: Vincent Massol It sems the current version in SVN trunk does not support generating the application.xml file. It does support adding EAR modules though. Generating application.xml would allow not having to hardcode the modules nor the version in the application.xml file. For example: ?xml version=1.0 encoding=UTF-8? !DOCTYPE application PUBLIC -//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN http://java.sun.com/j2ee/dtds/application_1_2.dtd; application display-nameSimple EAR for testing/display-name module web web-urisimple-war-0.6-SNAPSHOT.war/web-uri context-root/simpleweb/context-root /web /module /application -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POM issues in the repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In my opinion, this thread is not particularly useful. As far as I know, we have not called for a vote on the final release of Maven 2.0. (we haven't even released -beta-1 yet, for crying out loud!) This is my last reply on this thread; it is fast growing into another bitch session and waste of my time. See my comments inline. Maczka Michal wrote: | | a) build won't be reproductable If you're declaring your API dependencies correctly for your project, this absolutely should not have an impact on you. Any POM cleanup efforts should be directed at eliminating test-scope dependencies, or in some [extremely rare] cases, optional dependencies. The latter case should be covered by your project, since if it uses these optional parts, it should make some use of these same dependencies. | b) the scenario which you are proposing - everybody maintaining its own | maven repository with competing metadata even for open source projects | will become the reality. And this is something which in my opinion won't be | any good for maven nor for improving the quality of the maven central | repository. I already know some people which are creating their own m2 | repositories and the work which there are doing is not at all serving maven | community. I am all for centralising that effort. I know of people who won't use Maven or its repository because the artifacts aren't signed. Sure, there are going to be people who demand a higher level of quality than we are prepared to offer for the meantime; that is unavoidable. However, most users should be fine with the level of quality we can provide, particularly for the dependency use case. Project URLs and such are not as critical for this use case. | | Note then when I am saying that no POMs should not be changed - this means | that no dependency should be added, removed or moved to different position | witin the pom. The algorithm which resolves transitive dependencies is very | fragile: it is even (accordingly to my knowledge) sensitive to the position | of the dependency in the pom. If I understand correctly, you're alluding to the use of the nearest dependency-version taking precedence in a collision scenario. This is the default policy for m2, but doesn't have to be the only one. Before we release m2 final, we will allow (if we don't already) pluggable dependency-version conflict resolution policies. I don't agree that the transitive dep algorithm is so fragile, particularly when you change the version conflict policy...can you be more specific, or will this remain an unsubstantiated claim? | | I also have no better alternative to what's happening now with m2 | repository. But I share Vincent's opinion: | There needs to be a big effort to clean the m2 repo of bad POMs and I am | just adding that this in my opinion should happen and ___finish_ | before maven 2.0 will be proclaimed as final or even beta. Otherwise the | situation which happen with m1: some people tried unstable beta versions and | never come back to maven will be repeated one more time. But this time it | won't happen due to the code quality (which is really excellent in case of | m2) but due to the repository related problems. Michal, for me, here's the real bottom line: You're perfectly willing to contribute page after page of email complaining about maven 2.x and its repository. Yet your name doesn't appear on a single MEV JIRA issue (used as a TODO list to help improve the quality of the repository), and you haven't submitted a single issue to the MNG (maven 2.x) JIRA project. You seem to reiterate that we need to do all of this work to get Maven and its repo in shape, but are completely unwilling to do anything but talk about it. If you're concerned about Maven, then you need to know this: no matter what timeline we adopt for Maven's 2.0 release (and deadlines are critical for progress), we will never be ready according to the above criteria if our *very* small development team has to comb through the entire repository and assess the quality/correctness of each individual POM. Additionally, it is simply unreasonable to expect m2 to be relevant to the community in any way if we cannot provide a repository comparable to the m1 repository from day one. My advice: If you're unhappy with the state of the m2 repository, then by all means show us where the problem areas are. Submit a MEV issue or two, if you will. But cracking a whip over our heads without contributing anything the least bit constructive doesn't in any way help this development process. Regards, - -john -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFC0CyGK3h2CZwO/4URArOJAJ90P+evqoN5jVTgdR+nanDP3m1jKgCdF0X9 Adm2p+8xUj1sQqdLUAWw5gw= =0ki0 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/09-Jul-2005_04.00.58/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/09-Jul-2005_08.00.19/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/10-Jul-2005_12.00.20/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
