Re: [Discussion] Continuum 2.0 Roadmap
Rahul Thakur wrote: Overall I think the core of Continuum should be re-though to be more pluggable. In particular a workflow engine should be in the middle of the execution to orchestrate any steps involved with building a project. This is one of the places where people should be able to plug in their own steps and functionality. Is this close to what you are thinking? http://www.eclipse.org/alf/index.php After a 30 second look, I don't think so. More like this: http://www.jboss.com/products/jbpm -- Trygve
Re: [Discussion] Continuum 2.0 Roadmap
Rahul Thakur wrote: snipped 1-2)I would like to bring Guice to the mix. I think it is worth investigating for Continuum 2.0 - WDYT? I need a reason to drop the current set of technologies, why is the new set better etc. My motivations behind this were: # leverage Java 5 language and other library features, and enable Continuum to do the same. # Encourage more contributions by using tools/libraries that have a good user base. snipped 3) Builders Build definitions Just thinking out loud here... Does anyone else see the current Continuum model to be centered around 'Project'? What do you think about 'Build' or BuildDefinition being central? You can add one or more Projects to a Build - we don't need Project Groups, as all we deal with is a Build. Order and dependency can be imposed on a Build composed of more than one project. Notifiers are added to a Build and BuildResult(s) produced for a Build. This is way to detailed to be on a roadmap. Yep, way too detailed for the roadmap but that was just a random thought, please ignore it at this stage ;-) snipped 8) Installation Lastly, I think it would nice to have a core Continuum install to be lean and small with features that can be added by dropping in relevant JARs (and minimal or no configuration). We can actually try different options with development releases before finalizing what should go into the main distro (if at all we break it up) - sounds reasonable? I'm not sure what you're trying to say here. The current way to installing Continuum (unpack, run bin/plexus.sh) is still giving me wow when doing demos. I was just hinting if Continuum dist could be leaner, but again may be too early at this point in time Leaner in what way? What I would like to see is talk about the different ways of doing remoting and tool integration (IDEs in particular, but also desktop widgets). +1 Overall I think the core of Continuum should be re-though to be more pluggable. In particular a workflow engine should be in the middle of the execution to orchestrate any steps involved with building a project. This is one of the places where people should be able to plug in their own steps and functionality. +1 If someone is going down the plugin path, it is essential to me that these plugins can be written in vi inside an existing installation and copied around. This implies to me that we have to support a plugin language like jython, jruby or groovy. I agree with the possibility supporting multiple plugin languages in the long run but just having support for Java based plugins for starters. I am not yet sure what all is involved in supporting plugins in other languages. I didn't mean to say that Continuum should support *multiple* languages, only that it should support *a* language. My point was that when people are to customize their server they shouldn't have to start an IDE to create plugin. It should be possible to just mock around with some plugin files on the command line. -- Trygve
Re: [vote] Request Graduation to a TLP
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 +1 -- Trygve
Re: Javapolis 2007
I'm there! :) Vincent Massol wrote: On Nov 27, 2007, at 11:40 AM, Stephane Nicoll wrote: ZZzzz. Anyone awake? Vincent M., read your mail. I know you're coming! Yep, I'm coming :) XWiki will even have a huge booth as part of the ObjectWeb consortium. See you there! -Vincent On Nov 25, 2007 11:32 AM, Stephane Nicoll [EMAIL PROTECTED] wrote: Just wondering who's coming to Javapolis in two weeks? I'll be there so if you're coming, let me know :) Stéphane -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - 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: long delay between maven completion and build completion
Brett Porter wrote: I'm seeing this on the zone: INFO | jvm 1| 2007/09/24 03:29:17 | 2007-09-24 03:29:17,421 [pool-1-thread-1] INFO ContinuumBuildExecutor:maven2 - Exit code: 0 then for a long interval, on the web interface, the build is still in progress. It doesn't happen all the time, though. The log is already saying: [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 6 minutes 4 seconds [INFO] Finished at: Mon Sep 24 03:29:17 GMT+00:00 2007 [INFO] Final Memory: 14M/255M [INFO] The build finally completed after 10 minutes: INFO | jvm 1| 2007/09/24 03:33:58 | 2007-09-24 03:33:58,430 [pool-1-thread-1] INFO BuildController:default- Performing action deploy-artifact Note that the build result had said it was going for 8, 9, 10 minutes as it kept going, but then after finishing completely it reported the duration as 6 min 8 sec Any ideas? Initial hunch says signaling between the external process and the JVM. Do you see this on all platforms? In particular a UNIX platform vs Windows What about with running non-jvm builds (IWO shell scripts)? I have no time to debug this right now, but perhaps in a couple of days. -- Trygve
Re: [discuss] Graduate Continuum to its own TLP
Emmanuel Venisse wrote: Hi, At the begin, Continuum was designed to support maven2 projects so we thought it was good to put it under the maven umbrella. But now it supports other project types (ANT, shell scripts) too so it isn't centered on maven projects. An other thing is that we have lot of users (not only maven users) with actually 450 subscribers to the users list, and I think we can get more with a TLP project. My last point is that with the maven project, it isn't easy to add new committers because a new committer have the hand on all maven umbrella code and not only one project. So I think it would be good for Continuum to become a Top Level Project at ASF and the continuum community will have more chance to grow. My concern for the moment is we don't have enough committer from different companies, To be stable, at least 3 committers from different companies would be good. WDYT? I think Continuum fits both under the Maven umbrella and and a separate TLP on Apache and I would support both outcomes. -- Trygve
Re: APTEditor + Doxia
Lukas Theussl wrote: Vincent Siveton wrote: Hi Math! I recently add a pointer on your tool, so I am aware about your tool. 2007/7/25, Mathieu Avoine [EMAIL PROTECTED]: Hi everyone, I'm developing an Eclipse plugin called APT Editor which, like its name suggests, is an editor/viewer for APT files. Basically, it offers an edit pane to update the contents of the document, and a view pane to preview the formatted version of the document in HTML. It is a great tool for dev. We could have a live renderer. The project page is http://apteditor.sf.net Some people asked me if it was possible to offer the possibility to use Maven Doxia's parser/renderer instead of the original code from pixware. Sounds like a good idea to me, however not being a Doxia developer (not even a Maven user to be honest) I wouldn't know where to look. I'd appreciate if someone could give me some pointers as to how I could integrate Doxia with the APT Editor. To summarize, I'd need to know what libraries to load and what methods to invoke to generate an HTML version of a given APT file into a chosen directory. First, I suggest you to do a smart co of the doxia site http://svn.apache.org/repos/asf/maven/doxia/site We added lot of documentations these days. Would be nice if we could publish the new docs already (for people who are not familiar with maven to build the site themselves), at least somewhere on a stage site, or even live, since the main site is just user docs. WDYT? And another co from the full doxia project The apt parser is here: https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt Another link that might be useful is Trygve's doxia-editor: https://svn.apache.org/repos/asf/maven/sandbox/trunk/doxia/doxia-editor/ It's still in the sandbox and not very much advanced (it currently only does apt - xdoc conversion, and that not correctly... :( ), but from what I understand, it's supposed to be a stand-alone editor/renderer for any doxia-supported format. The biggest problem with creating an editor for Doxia is that Doxia has no object model, it is all about events which is a major PITA. The only thing that is usable from the editor I made is the stuff that builds the objects. -- Trygve
Re: [vote] release continuum 1.1-beta-1
Emmanuel Venisse wrote: Hi, I'd like to do a release of the 1.1-beta-1 +1, works for me. -- Trygve
Re: [vote] Move the maven-antlr-plugin to the mojo project
Jason van Zyl wrote: +1 On 14 Jul 07, at 8:33 AM 14 Jul 07, Vincent Siveton wrote: Hi, The last release (beta) of maven-antlr-plugin was more than two years ago. We did some small enhancements. http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11123fixfor=12931 A release could be done shortly but I would like to move the maven-antlr-plugin and maven-antlr3-plugin (in sandbox) to Mojo project. During the last year, I am the main committer on this project. Recently, David Holroyd provided a new plugin that supports Antlr v3, and submitted some patches. Unfornately, he is not an ASF committer. I could take care of David's patches but I think it should be good to give a new life of this project in the Mojo land. It would be more easy to give access to David, so he could maintain it as he wants. Vote is open for the usual 72 hrs. +1 -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Heads up regarding VMBuild
Brett Porter wrote: Hi folks, I'm currently doing the rounds of all the people using Continuum on VMBuild. The set up on there ballooned despite the box being underpowered and the installation intended to be experimental, so was never very well maintained. We have a new box to move vmbuild to now and with the features in continuum 1.1 I think we can make a decent go at it. I was going to set up the next release (with profiles and 'single module build' support) and start setting up projects on there and maintain it properly. Hopefully we can get some additional feedback in to the 1.1 final release. Is anyone interested in helping out? I must have missed that memo, what is VMBuild? A VMWare instance running continuum? -- Trygve
Re: [VOTE] Release Maven 2.0.7
Jason van Zyl wrote: Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ +1, works for me. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum Profiles
Emmanuel Venisse wrote: I don't know yet if we must add the second part in a second beta or in 1.2. The first part will change the database and the second part too. We'll need a migration tool between between actual db and first part and an other between first part and second part. Maybe we can change all db things in the first part so we won't need db migration between first and second parts. Do you know what will go to 1.2? It would be good to define it in jira. It shouldn't go into 1.1 as 1.1 is already way behind schedule and should focus on getting the features already in or scheduled to be added. The idea is good and I think it will be a very useful feature, but the focus should be on delivering a final 1.1 before anything else. -- Trygve
Re: [VOTE] Release source distribution for Archiva 0.9-alpha-2
Wendy Smoak wrote: On 5/18/07, Wendy Smoak [EMAIL PROTECTED] wrote: I'd like to release a buildable source distribution to go along with Archiva 0.9-alpha-2. Please review the archiva-0.9-alpha-2-src.tar.gz file and its companion checksums and signature, and then cast your vote. * http://people.apache.org/builds/maven/archiva/0.9-alpha-2/ ping. +1 from me, but I need a third PMC member to vote. +1 -- Trygve
Re: Specifying IntelliJ module name with maven-idea-plugin
[EMAIL PROTECTED] wrote:
Hi there,
I've notice that when using maven-idea-plugin, the module name that is
generated is based solely on artifact id.
Is there a particular reason for this? Why wouldn't it use project name
instead?
The reason I'm asking this is that we have three maven projects with
following structure,
project/
+- common/webapp/
+- customer/webapp/
Where artifact names are simply the name of the directory (e.g., webapp),
and I use final-name as ${groupId}.${artifactId}-${version} to control the
uniqueness of the actual artifacts file name that get generated.
Unfortunatly, with current maven-idea-plugin this results in a module
naming conflicting within IntelliJ. I think at the very least there should
be a way to specify generated IntelliJ module's name, using pom's project
name seems like a good idea to me.
Does anyone have any thought on this?
The artifact id is normally unique enough, but your idea is still useful
so please file an issue in JIRA[1].
[1]: http://jira.codehaus.org/browse/MIDEA
--
Trygve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r535724 - in /maven/continuum/trunk/continuum-webapp/src/main: java/org/apache/maven/continuum/web/bean/ProjectGroupUserBean.java webapp/WEB-INF/jsp/projectGroupMembers.jsp
[EMAIL PROTECTED] wrote: Author: oching Date: Sun May 6 20:34:07 2007 New Revision: 535724 URL: http://svn.apache.org/viewvc?view=revrev=535724 Log: CONTINUUM-1256 Applied patch submitted by Teodoro Cue Can you please include some information about what changed when committing stuff? It's annoying having to go through the patch and/or read the issue for smaller stuff. [snip] -- Trygve
Re: XML RPC security
Rahul Thakur wrote: Sounds good! Pointers would be great, if you have it handy :-) If you're using the servlet way (which I'd recommend) you should be able to use Redback as a filter for that URL. Way easier that my hack. -- Trygve TIA, Rahul - Original Message - From: Trygve Laugstøl [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Saturday, April 28, 2007 12:14 AM Subject: Re: XML RPC security Rahul Thakur wrote: Hey guys, Some quick notes on the security for XML RPC interface. This is what I am thinking... Have an AuthenticatedXmlRpcService component that services the xml rpc requests. The first request from a client to the service is a request for authentication. A successful authentication returns an authentication Token, which is passed along with subsequent requests by the client. A Token can go stale (configurable time period?) if there were not requests detected for it. Also, we could have a service that answers any polling requests and keeps a Token 'alive'. How about using HTTP and Redback for security? We can make the XML-RPC server listen on localhost:8000 only and then make a servlet that is proxying to localhost:8000/xml-rpc. The proxying servlet should come after a Redback security filter. I made a servlet like that once acting as a facade for a Subversion repository which I think I added to Plexus (aka the kitchen sink), if not I can dig it up for you. -- Trygve
Re: XML RPC security
Rahul Thakur wrote: Hey guys, Some quick notes on the security for XML RPC interface. This is what I am thinking... Have an AuthenticatedXmlRpcService component that services the xml rpc requests. The first request from a client to the service is a request for authentication. A successful authentication returns an authentication Token, which is passed along with subsequent requests by the client. A Token can go stale (configurable time period?) if there were not requests detected for it. Also, we could have a service that answers any polling requests and keeps a Token 'alive'. How about using HTTP and Redback for security? We can make the XML-RPC server listen on localhost:8000 only and then make a servlet that is proxying to localhost:8000/xml-rpc. The proxying servlet should come after a Redback security filter. I made a servlet like that once acting as a facade for a Subversion repository which I think I added to Plexus (aka the kitchen sink), if not I can dig it up for you. -- Trygve
Re: What is the Best practice for generating variations of an artifacts?
Franz Allan Valencia See wrote: Good day, Anybody want to comment on [1]. I think this has already been asked several times, and it would be interesting what the other developers would suggest as the best practice :-) I wrote [1] on the subject a while back. [1] http://blogs.codehaus.org/people/trygvis/archives/001296_building_for_different_environments_with_maven_2.html -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
Brett Porter wrote: I think it's more complicated than just removing that. Firstly, large numbers of command line plugins will stop working. Secondly, we need to provide a solution for implied plugins (we can set the version in the lifecycle and then let the user give pluginManagement to override it, but I'd like to see plugin 'packs' as a better solution to reduce the amount of configuration needed). Thirdly, we need to think carefully about the impact on existing builds. We're not just impacting the people that wrote the build - we impact the random people that grab a project and unwittingly try and build it with 2.1 not knowing the author never tested that, and get the bad experience. I'm still in favour of a compatibility mode that can be driven by the prerequisites or the modelVersion. I say let people use the dependency plugin now to start fixing their builds, but for 2.1 let them make the conscious decision to move up to this. I've talked about this before and I still mean that Maven should have a prerequisite flag for Maven version as you're saying. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn -Dtest=false = mvn -Dmaven.test.skip=false
Jason Dillon wrote: I just found out that -Dtest=false is the same as -Dmaven.test.skip=true... for those that don't like to type so much... FYI. -Dmaven.test.skip=true will in addition not compile the tests vs -Dtest=false will only skip execution. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Behavior philosophy. Was: Re: [vote] MNG-1577 as the default behavior
Jason van Zyl wrote: Hi, After working with it a little this week I would like to propose to make MNG-1577 behavior introduced the default. Builds are completely and totally unpredictable without this behavior. The behavior in 2.0.5 is fundamentally broken. To are totally prey to any dependency introduced by a dependency which makes no sense and completely counter intuitive. I stabilized a massive build this week simply by using the behavior present in the 2.0.x branch. I don't think we're doing anyone any favors leaving the old behavior in. After watching a disaster be recovered by using this new behavior I feel that the patch should go in as is and become the default behavior. This puts the user in control which is the way it should be. I propose we make this the default behavior. Can anyone think of a case where this degree of control would break an existing build? This patch saved my bacon this week, I think this behavior makes a world of difference to users. It seems that this discussion has settled down by now and I'm fine with the conclusion you guys have come up with. However, I would like to make one point. I see that the discussion has been confused with silly/dump/whatever dependency resolution vs silly/dump/whatever, but *predictable*, dependency resolution. If this patch would in any way change dumb, silly, retarded, awkward *predictable* dependency resolution I would have voted -1 to it. We cannot change the behavior in a bugfix release, no matter how trivial and sane it will be. We just can't do it. Adding an option to enable the good method would be a way around, and it *might* be done in a 2.1 release as it would make life better for everyone, but even then we're violating the rules of never changing behavior. I would like comments on this *philosophy*, not the issue in question. A workaround for this would be to change the XSD and say that the XSD specifies the behavior which is the only thing that makes sense to me. The model version should imply behavior. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/ doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Brett Porter wrote: On 19/03/2007, at 11:27 AM, Jason van Zyl wrote: You mean in a separate subproject of doxia. I can change the directory so how about: doxia doxia-site (sub project) doxia-book (sub project) These sound fine to me. Me too. What is the most important aspect of Doxia given how many plugins you can write for it is the external APIs and how you use Doxia in an embedded fashion. [snip] -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archiva logging of requests for artifacts
Wendy Smoak wrote: A recent version of Archiva is logging everything about incoming requests, but I don't see anything about the requests it makes out to proxied repositories. After deleting junit from both the local repository and the proxy-of-central 'releases' repo served by Archiva, I see the following when building a simple project (below). Can we change this to a single line for the request, and have it log any requests it makes out to proxied repositories? Just as a comment, this is something that would be perfect to distribute internally as events to a pluggable set of event listener. I'm sure this information is something people would like to be able to audit and possible veto based on company policies. -- Trygve
Re: Behavior philosophy. Was: Re: [vote] MNG-1577 as the default behavior
Jason van Zyl wrote: On 20 Mar 07, at 7:45 AM 20 Mar 07, Trygve Laugstøl wrote: Jason van Zyl wrote: Hi, After working with it a little this week I would like to propose to make MNG-1577 behavior introduced the default. Builds are completely and totally unpredictable without this behavior. The behavior in 2.0.5 is fundamentally broken. To are totally prey to any dependency introduced by a dependency which makes no sense and completely counter intuitive. I stabilized a massive build this week simply by using the behavior present in the 2.0.x branch. I don't think we're doing anyone any favors leaving the old behavior in. After watching a disaster be recovered by using this new behavior I feel that the patch should go in as is and become the default behavior. This puts the user in control which is the way it should be. I propose we make this the default behavior. Can anyone think of a case where this degree of control would break an existing build? This patch saved my bacon this week, I think this behavior makes a world of difference to users. It seems that this discussion has settled down by now and I'm fine with the conclusion you guys have come up with. However, I would like to make one point. I see that the discussion has been confused with silly/dump/whatever dependency resolution vs silly/dump/whatever, but *predictable*, dependency resolution. If this patch would in any way change dumb, silly, retarded, awkward *predictable* dependency resolution I would have voted -1 to it. It's entirely not predictable. Anyone asked how they thought depMan works would answer in accordance with the work in MNG-1577. They do not expect the behavior that is there before it. We cannot change the behavior in a bugfix release, no matter how trivial and sane it will be. We just can't do it. Adding an option to enable the good method would be a way around, and it *might* be done in a 2.1 release as it would make life better for everyone, but even then we're violating the rules of never changing behavior. I would like comments on this *philosophy*, not the issue in question. In theory I would agree. But we've gone against this several times. When? In this case there was talk about changing behavior that would potentially break existing builds as it wasn't determined if it was predictable or not. A workaround for this would be to change the XSD and say that the XSD specifies the behavior which is the only thing that makes sense to me. The model version should imply behavior. The problem here is that a static model cannot imply the behavior of a dynamic system. In this case the XSD would be exactly the same would describe nothing regarding how one dependency is selected over another. The static model cannot reflect dynamic nature of artifact resolution. Unless you are referring to something in the model which said what it was going to do and as we discussed (Ralph brought it up) that it would be a maintenance nightmare. What we would ultimately have to express in this case is that we were wrong and not providing the behavior that anyone expects and that we had corrected it. Cumbersome instead of providing a default mechanism that does the right thing. In this case we're fortunate that it will bring far more benefit then harm. I think we've done the right thing in this case and the result will be users will be better off. Ok, using the model version is quite possibly wrong but there could/should be a field indicating the expected behavior making room for these kind of changes. An alternative is to take a look at the required Maven version to use that as pointer to which behavior to use. Leaving the specifics of this issue, imagine what will happen if the plan of very frequent (1 month) release intervals will be implemented and within the next two years there will be 20 Maven releases (all most likely with 2 as it's major version). If the behavior suddenly changes randomly between point releases people will suffer way more as everyone in a team has to standardize on a certain Maven version and then we've suddenly lost a lot of the things we wanted to gain by putting a version field on everything. By having such a high number of releases you can be sure people will use the different versions all the time. I cannot stress the need to keep the behavior *very* stable. A dump (but not wrong) choice made by a developer should not be allowed to suddenly break (clumsy) but working builds. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/ doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Jason van Zyl wrote: On 20 Mar 07, at 7:57 AM 20 Mar 07, Trygve Laugstøl wrote: Brett Porter wrote: On 19/03/2007, at 11:27 AM, Jason van Zyl wrote: You mean in a separate subproject of doxia. I can change the directory so how about: doxia doxia-site (sub project) doxia-book (sub project) These sound fine to me. Me too. What is the most important aspect of Doxia given how many plugins you can write for it is the external APIs and how you use Doxia in an embedded fashion. Agreed. The core should be free of any site/book stuff for the 1.0. Trygve do you see anything that can move out. Like the indexing stuff? That is probably most pertinent to books and sites, any thoughts to where that should live? Can't think of an obvious place right now. To me the design of Doxia is not very useful if you want to produce books and/or sites useful for anyone other than developers so I haven't put much work into Doxia after my book work last year. I have some big plans somewhere for Doxia 2 but that won't happen sometime soon. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing Maven SCM 1.0
Emmanuel Venisse wrote: Emmanuel Venisse a écrit : Trygve Laugstøl a écrit : Emmanuel Venisse wrote: Hi, I'd like to release Maven 1.0 in next weeks. As you can see, I updated jira for this version. Before to do it, we need to fix some major issues with some providers. [snip] The issues you listed are only technical issues with the provider, not something that should you from releasing 1.0 of the API. I think that at the same time that the API is releases we split out the providers from the API and give them their own release cycle. We have some changes in API like list and export commands. That makes it easier to release providers as necessary and we get a stable API that doesn't move (or doesn't move but is released) every time someone fixes an issue in the Foo provider. With 1.0 release, I'll release providers too with 1.0 version, then, providers will have their own release cycle with a version like 1.0.x for providers that use API 1.0, 1.1.x for providers that use API 1.1... An other possibility would be to release all when we want to release API or a provider like we do it in some other projects like Modello That is true, but I see no reason to do that in Modello either. Maven SCM will move much faster that Modello, in particular when new providers are added, it is kinda silly to release all the providers just because a new provider was added. -- Trygve
Re: Preparing for continuum-1.1-alpha-1
Jesse McConnell wrote: I think we shouldn't worry about making these actually releases cut with the maven-release-plugin. I say we just make a build and get it available for download. Also tag the continuum trunk accordingly. Then we ought to try to release a new alpha every few weeks until we have the alpha-# issues converging towards 0. Why not? Using the Maven plugin is generally easier than doing it by hand. Only issue that comes to mind are snapshots dependencies. having to resolve the snapshot dependencies are precisely the reason I didn't want to mess with the maven release plugin for this. I would have to release a new plexus-security and probably a couple of other little higgly piggly bits. I think we can get by with the timestamped SNAPSHOT dependencies for these things, means we can release alpha's more frequently as well since we don't have to deal with micro-releasing the dependencies each time. +1 for timestamped snapshots. Can we get these pushed to the releases repository so it's possible to build the alpha later? Or perhaps we don't care about the exact reproducibility of the alphas? People can build the dependent sources from subversion after all (yay open source). Seems like a good pick, but I have a couple of comments: CONTINUUM-253: why? can't it be done after the release? it can, it is just done partially in a couple of places and I thought it might be nice to have that all collated together, but yes..it can be pushed a bit I'm just trying to push, it's totally up to you as you're doing the work and I'm just bitching. CONTINUUM-827: sounds to me like this is something that can take a while, is it worth waiting for? Remember that the target for the next alpha should be within a month. fine by me :) What is the time estimate on completing all of the issues? I want to see this pushed this week and then every couple of weeks from here on out. Shibby. -- Trygve
Re: Archiva Database future.
Joakim Erdfelt wrote: Databases in Archiva. I need *desperately* to create a proper database for Archiva. Relying on the Lucene database for all things in Archiva is not cutting it. But I'm waffling on the database O/RM technology to use. Here some Archiva requirements for the O/RM db technology. 1) Need to be able to handle objects managed outside of Archiva. Why? It is very important to me to separate the internal API/model from the external API and model. They will be very similar in the beginning but will after a few releases start to differ and is necessary to stay backward compatible with old clients. We're already seeing this happening in Continuum 1.1 and is a natural way of developing code. There was once upon the time code in Modello to facilitate migrating objects from version to version when we tried to make Maven 2 read Maven 1 POMs (remember those days Jason?), which is why there are version fields on all attributes of a Modello model. I'm sure the same tricks can be used to make some xslt-like mapping structure in Modello to generate tools to copy data from internal to external objects. 2) Need to be able to work with objects managed by Archiva. 3) Needs to work with objects in without enhancements by O/RM. 4) Needs to support a wide variety of JDBC datasources. 5) Needs to be ASL license compatible. 6) Needs to be Open Source. 7) Need ability to upgrade schema of previously installed Archiva. 8) Needs to be quick. 9) Need to be active and support project. 10) Need to support arbitrary lookups across DB tables for reporting reasons. So, when I looked at the technologies out there, this is what I see. JPOX: Violates #3, #7, #8, #10. Hibernate: Violates #3, #5, #7, #10 OJB: Violates #3, #7 OpenJPA: Violates #3, #7, #10 iBatis: -- The problem I have with most of the O/RM technologies are around #3. The long term plans of Archiva are to create supporting technologies around the XML-RPC interface to the data that Archiva is tracking. Having enhanced objects would cause the clients to Archiva to also have these enhanced classes as well as the O/RM supporting jars. An unacceptable situation. Another big concern is #7 or how to upgrade the database schema between archiva releases. Most of the O/RM technologies above do not make it clear how they do that. So I dinged them. iBatis on the other hand makes it extremely clear. It doesn't manage the Table creation. The developer does it. The last concern is #10, or how well the O/RM technology can deal with arbitrary and dynamic lookups into the tables without working with the objects. Such as the needs of a reporting system. I would like to hook up the database tables to the various reporting libraries and presentation widgets without having to worry about those queries being invalidated by changes made to the schema by the O/RM technology. One Note, all of the reporting usage patterns against the database that I see are read-only in nature. The process I am proposing is to use modello and ibatis. * Create our archiva-model using modello. * Generate java files for model definition. * Generate Create Table sqlMap.xml files. - One for each database type (hsqldb, derby, mysql, oracle, etc...) - Only for version 1.0.0 in modello model. * Generate Update Table sqlMap.xml files. - One for each database type (hsqldb, derby, mysql, oracle, etc...) - For each versions above 1.0.0 in modello model. * Generate CRUD sqlMap.xml files. - One for each database type (hsqldb, derby, mysql, oracle, etc...) - One for each object in modello model. * Generate java source for table version. (to aide in upgrade logic) * Generate java source for ibatis DAO layer. - One for each object in modello model. * Generate java source for sqlmap table create / update usage. I am going to be working towards this starting monday. Unless anyone has some suggestions or criticism on this approach. I would love it if you could summarize your findings on the wiki, including the information you have here so it's possible to see where which technology fails in terms of your requirement list. -- Trygve
Re: Preparing for continuum-1.1-alpha-1
Jesse McConnell wrote: I have gone through jira issues there were assigned to 1.1 and spread things out a bit. here is my criteria I used in separating out the issues: 1.1-alpha-1 - issues that need to be addressed asap before we pull any kinda alpha 1.1-alpha-2 - higher importance issues and ones generally related to xml-rpc 1.1-alpha-# - issues that probably ought to be resolved in the alpha releases Future - stuff that probably ain't going to get done any day soon the idea being that we can make new sequential release issues off of the 1.1-alpha-# release tag until we are done with alpha releases. I think once 1.1-alpha-1 is released then we can go through 1.1-alpha-2 and decide what should be done, make a new release called 1.1-alpha-3 and bulk move issues that aren't going to be addressed then (like maybe all the xml-rpc issues) I think we shouldn't worry about making these actually releases cut with the maven-release-plugin. I say we just make a build and get it available for download. Also tag the continuum trunk accordingly. Then we ought to try to release a new alpha every few weeks until we have the alpha-# issues converging towards 0. Why not? Using the Maven plugin is generally easier than doing it by hand. Only issue that comes to mind are snapshots dependencies. When we actually get to beta/rc releases then we can cut actual releases. Now about my allocation of issues, its not gospel! If you disagree with any of my assigning of fix versions then just fix it yourself (the version, or better yet the bug). At the time of this writing I have the 1.1-alpha-1 release down to a modest 8 issues with a few of those questionable and/or waiting for a bit of feedback. I have yet to go through the 200 or so unfiled issues though so that might go up a bit, I'll do that now. Seems like a good pick, but I have a couple of comments: CONTINUUM-253: why? can't it be done after the release? CONTINUUM-827: sounds to me like this is something that can take a while, is it worth waiting for? Remember that the target for the next alpha should be within a month. What is the time estimate on completing all of the issues? -- Trygve
Re: Preparing for continuum-1.1-alpha-1
Jesse McConnell wrote: sounds good to me, imo either trunc it or maybe switch the model over to a clob for that in the db... I tried to make it a CLOB once but couldn't get it to work because of some JPOX issues IIRC so for alpha-1 just chop the exception and/or write it to a separate file and put the ideal solution into a later alpha. Keep moving! -- Trygve jesse On 3/9/07, Stephane Nicoll [EMAIL PROTECTED] wrote: On 3/9/07, Jesse McConnell [EMAIL PROTECTED] wrote: I have gone through jira issues there were assigned to 1.1 and spread things out a bit. here is my criteria I used in separating out the issues: 1.1-alpha-1 - issues that need to be addressed asap before we pull any kinda alpha Not because I opened this but I think CONTINUUM-1194 should be fixed. I'll try to provide a patch this sunday for this. As a summary, if an error occurs and the stacktrace is higher than 8000 chars: * The build is stuck in Build In Progress * No notification is triggered (an error has occured?!) Thanks, Stéphane 1.1-alpha-2 - higher importance issues and ones generally related to xml-rpc 1.1-alpha-# - issues that probably ought to be resolved in the alpha releases Future - stuff that probably ain't going to get done any day soon the idea being that we can make new sequential release issues off of the 1.1-alpha-# release tag until we are done with alpha releases. I think once 1.1-alpha-1 is released then we can go through 1.1-alpha-2 and decide what should be done, make a new release called 1.1-alpha-3 and bulk move issues that aren't going to be addressed then (like maybe all the xml-rpc issues) I think we shouldn't worry about making these actually releases cut with the maven-release-plugin. I say we just make a build and get it available for download. Also tag the continuum trunk accordingly. Then we ought to try to release a new alpha every few weeks until we have the alpha-# issues converging towards 0. When we actually get to beta/rc releases then we can cut actual releases. Now about my allocation of issues, its not gospel! If you disagree with any of my assigning of fix versions then just fix it yourself (the version, or better yet the bug). At the time of this writing I have the 1.1-alpha-1 release down to a modest 8 issues with a few of those questionable and/or waiting for a bit of feedback. I have yet to go through the 200 or so unfiled issues though so that might go up a bit, I'll do that now. thoughts? jesse On 3/7/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: We don't need it the migration tool now. We'll can see to it when we'll release a first beta on rc. Emmanuel Brett Porter a écrit : On 07/03/2007, at 9:52 AM, Jesse McConnell wrote: Ok, well the little poll thread I made seemed to be strongly in favor of getting things pulled together to start getting alpha releases out of continuum. So with that in mind here is a list of a few things that we need to get in order for an alpha release that I shamelessly started base on bretts comments - properly mark up the model as it was for 1.0.3 release - add methods to continuum-data-management to utilise that and then make any necessary transformations (c-d-m will do the basic 1-to-1 conversions) - probably write a little CLI to fire it off. - vet jira for a 1.1 alpha 1 release version and maybe schedule out a couple of alpha-# releases. I think I'll start in on the data management bit now since that seems like the biggest hurdle. I am not convinced we really need to worry about a continuum 1.0.3 - continuum 1.1 migration ability...its not a difficult thing to get projects loaded back up into continuum...but we'll see I guess. It is a pain, but having said that we could potentially add it in a later milestone. I wouldn't want a final version without it. anyone have anything to add? jesse --jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Does this feature already exist?
It is indeed similar but Erik's thing will build it against *all* compatible versions, where compatible means within major upgrades (a x.y.z pattern is assumed). -- Trygve Jesse McConnell wrote: erik I saw this issue and thought of you :) http://jira.codehaus.org/browse/CONTINUUM-45 jesse On 3/8/07, Erik Drolshammer [EMAIL PROTECTED] wrote: Brett Porter wrote: On 08/03/2007, at 11:47 AM, Erik Drolshammer wrote: Did this make it clearer? yes Has Continuum 1.1 anything that resembles this? no Puuh. I was a bit scared now. Kind of. this would certainly facilitate it though. cool! I hope so. :) -- Regards Erik
Re: [vote] Trying to use standard versioning
Kenney Westerhof wrote: +1, as long as it's done like this: - use major.minor on trunk - major.[minor+1] is either api breaking or has new features - bugfixes should be major.minor.micro, from a maintenance branch for major.minor. Minor releases can't break APIs, we agreed on that a long time ago. Minor releases can only add functionality. so -0 on bugfix versions in the poms on trunk. I don't understand why you don't want to keep the mainline work on trunk? When 2.1 is release should we branch it into /branches/2.1.x immediately and leave trunk/ dead for 6 months? -- Trygve -- Kenney Jason van Zyl wrote: Hi, The impetus for this is wanting to release the surefire plugin that has a tiny bug in it. We are versioning our Maven release major.minor.micro so why don't we do the same with our plugin and treat everything like we're going to do small incremental releases like we should be doing. I would like to change all the versions on plugin to follow the major.minor.micro format starting with the surefire plugin. Thanks, Jason. - 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: [vote] Trying to use standard versioning
+1 with the same remark about not having the trailing .0 on the first release. Brett Porter wrote: +1 (I was going to do that with the 2.3 release, except that it had had junit4 support added). Aesthetically, I prefer to drop the trailing 0 on a first point release, but don't mind either way as long as we're consistent. - Brett On 02/03/2007, at 10:20 AM, Jason van Zyl wrote: Hi, The impetus for this is wanting to release the surefire plugin that has a tiny bug in it. We are versioning our Maven release major.minor.micro so why don't we do the same with our plugin and treat everything like we're going to do small incremental releases like we should be doing. I would like to change all the versions on plugin to follow the major.minor.micro format starting with the surefire plugin. Thanks, Jason. - 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: Maven's ArtifactMetadataSource's bad role-hint
Jason van Zyl wrote: On 4 Mar 07, at 3:18 AM 4 Mar 07, Andrew Williams wrote: Are there an objections, or reasons not to change the role-hint of MavenMetadataSource in maven-project from maven to default. I think that's fine, but we should also annotating all the plexus components and I think we can make this work with the bootstrap in much the same way we get modello to work. This will save much aggravation, it will then all be generated and adjustments to the CDC where required will make this much less painful. I'd rather not change all the source code. IMO the container should just add default as the role hint. As far as I can this will be required to keep compatibility with existing components. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r512016 - /maven/sandbox/trunk/plugins/maven-dependency-plugin/pom.xml
Jörg Schaible wrote: Dan Tran wrote: I think you broke the convention of 2 spaces indentation for xml file ;-) Well, no. All the lines had tab indention except the new ones I added. So I converted them into tabs also ;-) The convention is 2 spaces as indent so please fix the previous developer's work and keep it consistent :) -- Trygve - Jörg On 2/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: joehni Date: Mon Feb 26 13:19:19 2007 New Revision: 512016 URL: http://svn.apache.org/viewvc?view=revrev=512016 Log: Format new XML part. Modified: maven/sandbox/trunk/plugins/maven-dependency-plugin/pom.xml Modified: maven/sandbox/trunk/plugins/maven-dependency-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/sandbox/trunk/plugins/maven-dependency-plugin/pom.xml?view=diffrev=512016r1=512015r2=512016 == --- maven/sandbox/trunk/plugins/maven-dependency-plugin/pom.xml (original) +++ maven/sandbox/trunk/plugins/maven-dependency-plugin/pom.xml Mon Feb 26 13:19:19 2007 @@ -217,11 +217,11 @@ artifactIdplexus-container-default/artifactId version1.0-alpha-9/version /dependency -dependency - groupIdorg.apache.maven.shared/groupId - artifactIdmaven-dependency-analyzer/artifactId - version1.0-SNAPSHOT/version -/dependency + dependency + groupIdorg.apache.maven.shared/groupId + artifactIdmaven-dependency-analyzer/artifactId + version1.0-SNAPSHOT/version + /dependency /dependencies !--reporting plugins - 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: error on continuum rpc server
Andrew Williams wrote: OK, not entirely sure what to do about this problem now... Calling getBuildResultsForProject over RPC yields this exception on the server side. Caused by: javax.jdo.JDODetachedFieldAccessException: You have just attempted to access field modifiedDependencies yet this field was not detached when you detached the object. Either dont access this field, or detach the field when detaching the object. at org.apache.maven.continuum.model.project.BuildResult.jdoGetmodifiedDependencies(BuildResult.java) at org.apache.maven.continuum.model.project.BuildResult.getModifiedDependencies(BuildResult.java:219) ... 20 more Does anyone have suggestions on how to fix this? IIRC you can set fields that the XML-RPC tool shouldn't try to unmarshall when crawling the object graph. But as I wrote this two years ago or something my mind might be slipping :) I'm going to be reading Continuum source code all afternoon today so if you ping me on IRC we can see if we can figure it out there. -- Trygve
Re: Plans for Wagon-1.0 final release?
John Casey wrote: Hi, I just committed some changes to trunk that should restore backward compatibility for using older wagons (at least in the vast majority of cases). It may still break if there is an older version of a wagon out there that doesn't extend from AbstractWagon (since the Wagon interface picked up like 5 new methods lately). Can we start talking about a Wagon 1.0-final release? What do we need to get this done? It looks like the current roadmap only shows 3 outstanding issues for the next release. Does anyone have plans for finishing those, and are they enough to serve as a basis for a final release? I'm just trying to figure out what plans there are for this, since I'd like to move toward a 2.1-alpha-1 release of maven, and this is going to be a prereq. I say release what Wagon is now as 1.0 (in other words no API breakage) and put Joakim's plans into Wagon 2.0. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Poll: release continuum alpha
Stephane Nicoll wrote: On 2/23/07, Trygve Laugstøl [EMAIL PROTECTED] wrote: A milestone should focus on showing the fancy new features and bugs fixed. Stuff like security, upgrading existing databases etc are all secondary. I understand what you mean but I think database upgrade is very important because users will want to test continuum 1.1 with their data. This first release will also give you a chance to test your upgrade procedure. Given than adding projects to Continuum is so easy it is (imo) not an important option and should in no way stand in the way of a *milestone* release. To me this release is important for two different cases: 1) The last release was April 25th 2006. That is close to a year and I doubt 1.1 will be out by April 25th 2007 in any case, I would have serious issues voting on a release that you can't say is done today and start testing from now till the 25th. The point is that the users need to see progress in features and stability. 2) There are as far as I know only old developers working on Continuum these days and by getting stuff out it will hopefully spark a few people to start contributing patches and possibly become developers. I'm also sure a lot of bug reports will be filed and the development will make sure that they're going in the right direction. -- Trygve
Re: Poll: release continuum alpha
Jesse McConnell wrote: I was talking to trygve a bit on irc and it dovetailed nicely with some plans I had talked about late last year in regard to continuum...I am just about a month late is all. We thought we ought to take a poll on here about continuum and see what folks thought. This is not a vote, its just a poll and perhaps a discussion starter on short to mid term plans with continuum. I just know it bothers me a bit everytime someone pops on IRC and asks questions about continuum 1.0.3...which is quite aged atm with so many of the bugs on it resolved on the trunk. Question: Should we take all the work that has been done on continuum in the last year+ and get it pushed out as an Alpha1 or a Milestone1 or some suitable equivalent? Yes, definitely. I feel bad every time I talk to someone using Continuum knowing that a whole bunch of annoying bugs are fixes and very useful features have been added. A milestone should focus on showing the fancy new features and bugs fixed. Stuff like security, upgrading existing databases etc are all secondary. This will give the community the ability to check in on the latest development and make sure that the developers don't stray too far away from what the users actually need. [+1/0/-1] I though you said that this wasn't a vote? ;) Thanks a whole lot for listening to me and taking the time to do this Jesse. I am very interested in getting 1.1 (or 1.0.4 if it has to be) out the door and can hopefully do some work for you guys. -- Trygve
oching, please subscribe to [EMAIL PROTECTED]
your commit emails are beeing moderated. -- Trygve
Re: Why is prerequisites not inherited?
Brian E. Fox wrote: Heh. Are you mocking me or just behind in thread mail? ;p BTW: Is this reply threading correctly now? Can't tell until you reply to this one as most email clients make threads based on the subject so it needs to be at least on the third level down in the thread tree. [snip] -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: License for POM files
Deepak Bhole wrote: Hi, What license are the pom files in the maven2 repository (repo1.maven.org/maven2) under? We need to know if we are allowed to redistribute those poms with Fedora. They either have the license of the project in question (as they come from the project) or they're written by us and thus (I assume) are covered by the Apache Software License. Some of the poms are also generated, but they are easy to spot. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r506479 - in /maven/continuum/trunk: continuum-api/src/main/java/org/apache/maven/continuum/ continuum-api/src/main/java/org/apache/maven/continuum/store/ continuum-core/src/main/java/
[EMAIL PROTECTED] wrote: Author: evenisse Date: Mon Feb 12 07:19:35 2007 New Revision: 506479 URL: http://svn.apache.org/viewvc?view=revrev=506479 Log: Fix some jdo calls for performance improvment Modified: maven/continuum/trunk/continuum-api/src/main/java/org/apache/maven/continuum/Continuum.java maven/continuum/trunk/continuum-api/src/main/java/org/apache/maven/continuum/store/ContinuumStore.java maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/DefaultContinuum.java maven/continuum/trunk/continuum-core/src/test/java/org/apache/maven/continuum/DefaultContinuumTest.java maven/continuum/trunk/continuum-store/src/main/java/org/apache/maven/continuum/store/JdoContinuumStore.java maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/ProjectGroupAction.java maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/SummaryAction.java maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/component/BuildDefinitionSummaryAction.java maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/component/NotifierSummaryAction.java Modified: maven/continuum/trunk/continuum-api/src/main/java/org/apache/maven/continuum/Continuum.java URL: http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-api/src/main/java/org/apache/maven/continuum/Continuum.java?view=diffrev=506479r1=506478r2=506479 == --- maven/continuum/trunk/continuum-api/src/main/java/org/apache/maven/continuum/Continuum.java (original) +++ maven/continuum/trunk/continuum-api/src/main/java/org/apache/maven/continuum/Continuum.java Mon Feb 12 07:19:35 2007 @@ -80,6 +80,9 @@ public ProjectGroup getProjectGroupWithProjects( int projectGroupId ) throws ContinuumException; +public ProjectGroup getProjectGroupWithBuildDetails( int projectGroupId ) +throws ContinuumException; Can we call this getProjectGroupWithBuildDetailsByProjectGroupId(..) to make it consistent? public ProjectGroup getProjectGroupByGroupId( String groupId ) throws ContinuumException; @@ -115,7 +118,11 @@ BuildResult getLatestBuildResultForProject( int projectId ); +Map getLatestBuildResults( int projectGroupId ); ditto here, Map getLatestBuildResults(); + +Map getBuildResultsInSuccess( int projectGroupId ); and here. Map getBuildResultsInSuccess(); [snip] -- Trygve
Re: [VOTE] Release Maven 2.0.5 (take 2)
Jason van Zyl wrote: Hi, The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/maven-core/2.0.5/ Here is the JIRA roadmap: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500fixfor=12294sorter/field=issuekeysorter/order=DESC +1, my stuff builds. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.5 and MNG-2794
I would like to see this additional requirement too. -- Trygve Kenney Westerhof wrote: Yup, I agree. but still the case where 2 matches are equally near should be solved; I think atm. this is either random or first/last-encountered-wins; this should be latest (so nearest wins, if equal distance then fallback to latest). But this could go in at 2.0.6 IMHO. -- Kenney Brett Porter wrote: Sounds right to me. Needs something mentioned in the announcement/release notes, though. - Brett On 12/02/2007, at 9:25 AM, Jason van Zyl wrote: Hi, After looking at MNG-2794 I don't think it's something we should fix change. The 2.0.4 release was working in a way contrary to our documentation in that the nearest with 2.0.4 was not being selected and it is with 2.0.5. So we either fix it and then it conflicts with what we document, or leave it and have work as documented. That particular test case also requires commons-collections for compilation and you should always specify directly any dependencies you need to compile your project. The details are in the comment, but I say we leave the behavior that is present in 2.0.5 now. http://jira.codehaus.org/browse/MNG-2794#action_87295 Thanks, Jason. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r501627 - in /maven/plugins/trunk/maven-repository-plugin/src/main/java/org/apache/maven/plugins/repository: BundleCreateMojo.java BundlePackMojo.java
[EMAIL PROTECTED] wrote:
Author: jmcconnell
Date: Tue Jan 30 14:59:27 2007
New Revision: 501627
URL: http://svn.apache.org/viewvc?view=revrev=501627
Log:
added $ back into the expressions, was throwing NPE in the test cases on the
jarArchiver
[snip]
/**
* Jar archiver.
- * @parameter
expression={component.org.codehaus.plexus.archiver.Archiver#jar}
+ * @parameter
expression=${component.org.codehaus.plexus.archiver.Archiver#jar}
* @required
* @readonly
*/
That syntax was deprecated a couple of years ago :)
Use
@component org.codehaus.plexus.archiver.Archiver#jar
instead
[snip]
--
Trygve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] merge id-refactor branch changes
Christian Edward Gruber wrote: Trygve Laugstøl wrote: 1.0 to a 1.1 is not the time when you break an API. You can add stuff with minor released, but not break things. This is the versioning conventions used for all Maven-related projects. Perhaps trunk should be 2.0, but as long as it's 1.1 it can't break the API. Well, in the Java world, this convention (While good) is not very well followed. I agree, however, that 1.1. should be backwards compatible in a good versioning system, so I support your notion that trunk should be 2.0. I think there is enough change that is substantial enough in operation and features that 2.x is probably a more useful description. This isn't a small increment in functionality. It is the standard we've been following for years. IMO there isn't a whole lot of features, just a bunch of (very useful) enhancements. To me there is no reason to break the existing API as from what I can tell there haven't been any fundamental changes in the APIs and concepts on how Continuum works. This is in no way meant as a critique to all the hard work all the guys has been putting in Continuum. I've heard nothing but good stuff from all the people I have gotten to try out Continuum trunk, many who are still running it in production. I thank all of you for your hard work! -- Trygve
Re: [vote] merge id-refactor branch changes
Christian Edward Gruber wrote: Um, 1.0 to 1.1 seems like the right time to break an api if you are going to eventually. Better if it were a 1.x to 2.x, but certainly it's not a 1.0.12 to 1.0.13 situation. I think it woudl be hard to argue on a purely needs basis. Apache as a whole is approaching 500,000 commits in their subversion repo over its lifetime, which couldn't amount to more than 4x results in any table, could it? What are the real characteristics of how many keys are generated given a repo of a certain size, etc? 1.0 to a 1.1 is not the time when you break an API. You can add stuff with minor released, but not break things. This is the versioning conventions used for all Maven-related projects. Perhaps trunk should be 2.0, but as long as it's 1.1 it can't break the API. I didn't understand the last part of your paragraph WRT to the Apache svn repository, please clarify it if I missed your point. Besides, the database will be broken and need migration or re-building between 1.0.3 and 1.1 anyway, so that's no barrier. If we're running 1.1-SNAPSHOTs, well, guess what... they're snapshots - not guaranteed to function the same upon release. Not reasons to do it, mind you, just rebuttals to some reasons to not do it. That is really not relevant in this case. We're talking about the external API for applications, not the database. Running a tool to alter the database is fine. -- Trygve Christian. Trygve Laugstøl wrote: Rahul Thakur wrote: 'int' ids are now converted to 'long' across the project and to allow really large values. This should cater to scenarios where the id generation could be started from an arbitrary large value. Won't this break the API? Yep, it would. What is the use case where 4 billion IDs isn't sufficient? 2 billion you mean :-). But this also more of something that I have noticed 'traditionally' that ids are specified as long and stored as bigints in database No, 4 billion. an int is +-2billion. Anyway, just because longs are more traditionally used that is not a good enough reason to switch to longs and break the API to me. -- Trygve
Re: [vote] merge id-refactor branch changes
Rahul Thakur wrote: Trygve Laugstøl wrote: Rahul Thakur wrote: 'int' ids are now converted to 'long' across the project and to allow really large values. This should cater to scenarios where the id generation could be started from an arbitrary large value. Won't this break the API? Yep, it would. What is the use case where 4 billion IDs isn't sufficient? 2 billion you mean :-). But this also more of something that I have noticed 'traditionally' that ids are specified as long and stored as bigints in database No, 4 billion. an int is +-2billion. Anyway, just because longs are more traditionally used that is not a good enough reason to switch to longs and break the API to me. Yep, I know, I was referring to the +ve 2 billions. I could say a case where Id generation could be set to start from a fairly large value and so are the Id sequence increments. One could argue this is an edge case ;-). Can you please come up with a realistic use case where IDs would start on something other than 0 or 1? The database is controlled by Continuum and is an internal thing which we have complete control over. IMHO the version change to 1.1 is a fair indication that the API might have changed. Having said that, I will go with whatever most of us think sounds practical :-) The only thing you can do is to add stuff, not break existing code. -- Trygve
Re: [vote] merge id-refactor branch changes
Rahul Thakur wrote: 'int' ids are now converted to 'long' across the project and to allow really large values. This should cater to scenarios where the id generation could be started from an arbitrary large value. Won't this break the API? Yep, it would. What is the use case where 4 billion IDs isn't sufficient? 2 billion you mean :-). But this also more of something that I have noticed 'traditionally' that ids are specified as long and stored as bigints in database No, 4 billion. an int is +-2billion. Anyway, just because longs are more traditionally used that is not a good enough reason to switch to longs and break the API to me. -- Trygve
Re: [vote] merge id-refactor branch changes
Rahul Thakur wrote: Hi, I'd like to request a vote to merge the id-refactor branch changes. 'int' ids are now converted to 'long' across the project and to allow really large values. This should cater to scenarios where the id generation could be started from an arbitrary large value. Won't this break the API? What is the use case where 4 billion IDs isn't sufficient? -- Trygve
Re: Build by Maven logo
Vincent Siveton wrote: Hi, I would like to hear your comments about the build by Maven logo (DOXIA-84) and the ASF feather. This logo is the out-of-box Maven logo, a lot of projects uses Maven for their documentation so it is an important advertising way for ASF Maven. IMHO the ASF feather should be into this logo. Thoughts? Natalie proposed a black and orange-colored version of the feather. WDYT to customize it? -1. The feather is the Apache logo, not the Maven logo. The Built by logo could however be styled with the Maven colors. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with ContinuumStoreTest
Erik Drolshammer wrote: Marcelo Fukushima wrote: On 1/18/07, Erik Drolshammer [EMAIL PROTECTED] wrote: Hi! I'm trying to set up a developement environment for Continuum, but I'm experiencing some problems; *tags/continumm-1.0.3* #mvn install = log4j:WARN Please initialize the log4j system properly. Where can I configure log4j? What to configure? that message from log4j is just a warning... i dont think it should be there, but it doesnt affect your build - meaning you have a diff problem You are right. It was just horribly slow. (It hangs on log4j three times during the build). Hang on Log4j how? Any ideas on the new problem? [ERROR] BUILD ERROR [INFO] [INFO] One or more required plugin parameters are invalid/missing for 'plexus:runtime' [0] inside the definition for plugin: 'plexus-maven-plugin'specify the following: configuration ... runtimeConfigurationPropertiesVALUE/runtimeConfigurationProperties /configuration -OR- on the command line, specify: '-DappProperties=VALUE' [INFO] Total time: 3 minutes 30 seconds If you look in the pom you can see that the value is set in two different profiles, one for test and one for production. Try running maven with -Penv-test to activate the test profile. -- Trygve
Re: Metrics Gathering Tracking
Rahul Thakur wrote: Jesse McConnell wrote: I was figuring we would add something like this as some kinda continuum extension for when the workflow is added to the continuum object. Is this going to be impelmented using plexus-spe or OS workflow? os-workflow is not what Continuum need, I tried that once (had a branch for it at one point). Plexus-spe should be a good start for Continuum, but it needs to be improved to be very useful. -- Trygve
Re: Trusting in our own dog food
Brett Porter wrote: so... you're saying you don't trust our dog food? :) No, I'm saying it's there to verify the dog food. If there is no discrepancies between what the cron is saying and the C instance is saying, it's good. If there is an discrepancy it's not good. It will be more a tool to verification tool that a CI (but that might be two sides of the same story :) -- Trygve The only thing it tests differently is: - works by cron, whereas continuum might go down/hang/something else (which is something we should work on fixing if it does, rather than rely on ci.sh) - runs a reactor (can add that as a less frequent build execution in continuum too, though). So, I don't see any reason to keep it - wdyt? - Brett On 11/01/2007, at 7:57 PM, Trygve Laugstøl wrote: Brett Porter wrote: Folks, I'd like to turn off continuum_ci.sh and instead only use Continuum itself to do CI for Continuum. Any objections? I don't see why it should be turned off, but perhaps the automatic notifications can be turned off or just send failures. That way it would verify the product (it will in itself be an integration test) because if the Continuum instance says that something is failing, you should expect an email saying the same right after. Or at least you can check the logs directory if you're suspecting some other failure. -- Trygve
Re: [VOTE] Release Maven 2.0.5
Trygve Laugstøl wrote:
Jason van Zyl wrote:
Hi,
The entire release is staged here:
http://people.apache.org/~jvanzyl/maven-2.0.5/
The assemblies that people are interested in are staged here:
http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/
Here is the JIRA roadmap:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500fixfor=12294sorter/field=issuekeysorter/order=DESC
That's about it. Play around with it, if there are things wrong and
I'll fix stuff. We haven't released in so long there very well may be
some problems.
We should probably let it sit until Tuesday as most folks won't try it
out over the weekend.
I'm waiting until I've tried it out on my projects.
Testes and a serious bug was found. It seems that Maven tries to check
for SNAPSHOT plugin updates on every run instead of the expected daily
interval.
I've verified that it do check on every update by using truss (use
strace on linux) on Solaris:
$ truss -t connect mvn -Dmaven.test.skip=true install
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - no.java.monitor:monitor-core:jar:1.0-SNAPSHOT
[INFO]task-segment: [install]
[INFO]
[INFO] artifact org.apache.maven.plugins:maven-resources-plugin:
checking for updates from codehaus-snapshots
/1: connect(8, 0xFFBFBAF4, 16, SOV_DEFAULT) = 0
/1: connect(7, 0xFFBFBD98, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking
for updates from codehaus-snapshots
/1: connect(7, 0xFFBFBD80, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
for updates from codehaus-snapshots
/1: connect(9, 0xFFBFBD98, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-jar-plugin: checking for
updates from codehaus-snapshots
/1: connect(7, 0xFFBFBD80, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking
for updates from codehaus-snapshots
[INFO] [plexus:descriptor {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[WARNING]
Artifact junit:junit:jar:3.8.1:test retains local scope 'test'
overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or
remove the local scope.
So I'm -1 on this revision until this issue is resolved :'(
The issue was confirmed by other devs on IRC aswell.
--
Trygve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5
Jason van Zyl wrote: Hi, The entire release is staged here: http://people.apache.org/~jvanzyl/maven-2.0.5/ The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/ Here is the JIRA roadmap: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500fixfor=12294sorter/field=issuekeysorter/order=DESC That's about it. Play around with it, if there are things wrong and I'll fix stuff. We haven't released in so long there very well may be some problems. We should probably let it sit until Tuesday as most folks won't try it out over the weekend. I'm waiting until I've tried it out on my projects. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trusting in our own dog food
Brett Porter wrote: Folks, I'd like to turn off continuum_ci.sh and instead only use Continuum itself to do CI for Continuum. Any objections? I don't see why it should be turned off, but perhaps the automatic notifications can be turned off or just send failures. That way it would verify the product (it will in itself be an integration test) because if the Continuum instance says that something is failing, you should expect an email saying the same right after. Or at least you can check the logs directory if you're suspecting some other failure. -- Trygve
Re: calling vote for 2.0.5
Jason van Zyl wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. Then I think it should be released. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. I don't think micro releases is the way to go in general, if you define micro releases to be in the scale of a a couple of weeks. The 7 months that has passes since 2.0.4 is too long, don't get me wrong but having very frequent micro releases is just going to confuse people and lead to inconsistent developer environments. Just a though on making bi-weekly/monthly micro releases the new way. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving site plugin webapp to another plugin
Jason van Zyl wrote: Can we put the webapp stuff that's currently in the site plugin in another plugin so that when you simply want to generate your site you don't drag down Jetty and all its dependencies? It really is something unexpected and isn't something most would associate with just generating a site. The functionality is cool, I just think it belong in another plugin. +1, it is as you say a bit of a surprise to downlown the J2EE stack to run javadoc or transform some APT :) -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] site layout for /maven/*
Vincent Siveton wrote: Hi, In the same way of Brett's thread [1], WDYT to move all /maven/*/*-site to /maven/site/*? Actually, archiva, jxr and doxia have no standard layout for site and problems of deployment can appear (throw a glance to [2] about doxia site). We could consolidate them instead of. Thoughts? I'm not sure if I see the why we'd like that as now the documentation is coupled to the source code which makes the most sense to me. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] site layout for /maven/*
Vincent Siveton wrote: Hi, 2007/1/10, Jason van Zyl [EMAIL PROTECTED]: On 9 Jan 07, at 7:18 AM 9 Jan 07, Vincent Siveton wrote: Hi, In the same way of Brett's thread [1], WDYT to move all /maven/*/*-site to /maven/site/*? Actually, archiva, jxr and doxia have no standard layout for site and problems of deployment can appear (throw a glance to [2] about doxia site). We could consolidate them instead of. Thoughts? I like the sites with the projects as I would like something that 1) Facilitates deploying the site as an artifact and 2) Having the documentation with the project you're documenting. Moving it all to one place doesn't make any sense to me. Agree. So, I propose to consolidate doxia project, ie move /maven/doxia/site to /maven/doxia/trunk/doxia-site WDYT to standardize archiva and jxr project like other sub projects? I mean creating archiva-site and jxr-site? -0, the site is a living thing that lives outside of the project itself. If the project has _documentation_ that is released with the project and deployed in addition to the site you can add doxia-site and make that contain the documentation for a particular version. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] iBatis, JPA and Java 5.0
Carlos Sanchez wrote: On 1/2/07, Rahul Thakur [EMAIL PROTECTED] wrote: - Original Message - From: Brett Porter [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Wednesday, January 03, 2007 4:59 PM Subject: Re: [discuss] iBatis, JPA and Java 5.0 I've been thinking stay with JDO for now, look at JPA in the long term. I haven't used iBatis, and would be happy to hear some practical experience from people who have. I tend to think of it as a more productive JDBC, as opposed to the different programming model of JDO/Hibernate/JPA. I haven't used it either, but that thread got me thinking about what would drive the choice of a persistence solution if we were rethinking jpox. I did use it and yes, it's a more productive JDBC. If you need to do low level stuff then go for ibatis, but I wouldn't do it for Continuum unless really needed, it's going to be pretty verbose. I agree with this, iBatis makes your code very verbose and it is not nearly as elegant as it coult be. I've been trying out out iBatis for a while not, and it's not really that much easier to program with than JDO, and if you have a rich object model like Continuum has it really is a pain to make sure you SELECT the entire model and UPDATE when storing. Doing dirty checking and fancy stuff like that that the OODB/ORM-style tools can do you can just forget about doing. I don't thing it's a good idea to have several implementations of the data store (JDO, ibatis, JPA,...), there's gonna be a lot of refactoring work and one will be the default while the others won't get a good level of stability not being widely used. I wholeheartedly agree that having many implementations of the store is not a good idea as other has said in this thread before, the different models are too different and there is no good reason to have many implementations at the same time. Branching and trying out a replacement is one thing, but there should not be multiple implementations at once. [snip] -- Trygve
Re: svn commit: r493534 - in /maven/plugins/trunk/maven-repository-plugin/src: main/java/org/apache/maven/plugins/repository/BundleCreateMojo.java test/java/org/apache/maven/plugins/repository/BundleC
Jason van Zyl wrote: On 8 Jan 07, at 3:26 AM 8 Jan 07, Trygve Laugstøl wrote: Jason van Zyl wrote: On 7 Jan 07, at 12:30 PM 7 Jan 07, Fabrizio Giustina wrote: On 1/7/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 6 Jan 07, at 1:45 PM 6 Jan 07, [EMAIL PROTECTED] wrote: MREPOSITORY-2 project.scm.connection should not be required for bundle-create Why not? the project could not have a public repository, there are projects that only distribute binary/source jars without having an accessible scm at all. Can you give me an example of an OSS project submitting something to the central repository that doesn't have a public repository? How can you operate as an OSS project without a public repository? There are already several examples on that there. There is nothing in the OSS licenses that requires the source to be publicly available all the time, only the parts that you distribute. No, there is nothing required other then a stipulation we would make. Some traceability for artifacts placed in the repository. My thinking is that at some point in the very near future submissions would be made in the form of giving us a POM we can use to build the code and push into the repository. That would be really cool. and a very useful feature for a lot of projects in the way that we could make sure that their POMs are good and that their released project's builds are actually re-producable. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] consolidate sandboxes
Brett Porter wrote: Hi, When we earlier opened the Maven sandbox to all ASF committers, I think it was the intention to do this for all sandboxes, but that wasn't the case in practice. To have a cleaner ACL, and cleaner externals on /trunks, I'd like to propose we consolidate the sandboxes. The structure would be: /maven/sandbox /maven /benchmark (from /sandbox) /maven-1.x-integration (from /sandbox) /shared /maven-artifact-tools (from /sandbox) /maven-repository-checker (from /sandbox) /maven-shared-jar (from /sandbox) /maven-shared-java-parser (from /sandbox) /maven-shared-license (from /sandbox) /plugins (as now) /other /acm (from /sandbox) /grafo (from /sandbox) /issue (from /sandbox) /marmalade (from /sandbox) /maven-dynamic-web (from /sandbox) /maven-metamorphosis (from /sandbox) /reports (from /sandbox) /ssh-tester (from /sandbox) /taxonomy (from /sandbox) /wiki (from /sandbox) /wagon /wagon-scm (from /sandbox) /scm (from /scm/trunk/sandbox) /surefire (from /surefire/trunk/sandbox) /doxia (from /doxia/trunk/sandbox) /continuum (from /continuum/sandbox) /archiva (from /archiva/sandbox) /maven-1-plugins (from /maven-1/plugins-sandbox) Thoughts? I'm not sure if I fully understood the layout, but if you want to move all the sandboxes from /maven/*/sandbox to /maven/sandbox/*, that's good. The structure underneath should be similar to what we have under /maven/. If this is what you meant, I'm +1. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven mirror rsync
Cody Zhang wrote: Dear Lady/Gentleman, I am a maven user. I follow the command (http://maven.apache.org/guides/mini/guide-mirror-settings.html ): rsync -v -t -l -r mirrors.ibiblio.org::maven2 /tmp/maven2 But, it is failure. Seems to be working for me, at least it starts to fetch the directory list. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Collapse Maven permission groups
Brett Porter wrote: Hi, Since there was no objection to calling a vote, as discussed in the proposal, I'd like to call a vote on this. To see the proposal and discussion: http://mail-archives.apache.org/mod_mbox/maven-dev/200612.mbox/[EMAIL PROTECTED] Vote to operate as - requiring 2/3rds of the PMC to vote (13), with a majority within those votes for it to pass (ie, add them all and if the result is 0). Other votes would be welcome with reasons as advisory, but not binding. - Votes can be changed at any time before result is posted. - Vote is open for at least 72 hours, completing once enough have voted after that. - There are two different +1 options. If there is a majority for collapse all groups against both other options, then it will pass. If it fails, then all votes will be transferred to the retain subproject access restrictions and recounted. The proposal is to collapse all access groups into a single ACL for Maven, with the following list of 37 committers: Fabrice Bellingard, David Blevins, John Casey, Maria Ching, Joakim Erdfelt, Dan Fabulich (pending), Brian Fox, Fabrizio Giustina, Arnaud Heritier, Jeff Jensen, Shinobu Kawai, Milos Kleint, Trygve Laugstol, Felipe Leme, Dennis Lundberg, Vincent Massol, Jesse McConnell, Stephane Nicoll, Mike Perham, Brett Porter, Edwin Punzalan, Daniel Rall, Allan Ramirez, Carlos Sanchez, Vincent Siveton, Wendy Smoak, Torbjorn Smorgrav, James Strachan, Chris Stevenson, Rahul Thakur, Lukas Theussl, John Tolentino, Dan Tran, Emmanuel Venisse, Kenney Westerhof, Andrew Williams, Henri Yandell, and Jason van Zyl. The alternate proposal is to retain subproject access restrictions, so the groups will be (PMC members removed, as they retain access to all areas): maven=wsmoak,felipeal,jjensen,shinobu,dlr,mkleint,handyande,epunzalan,aramirez,dantran,chrisjs,brianf,bellingard,oching (/maven-1,/components,/plugins,/archetype,/core-integration-testing,/jxr,/release,/skins,/resources,/release-testing) doxia=dblevins archiva=bayard,epunzalan,oching continuum=dblevins,rinku scm=dantran,smorgrav wagon=empty at this time surefire=empty at this time All of the above groups will have access to: /pom, /project, /site, /shared in this proposal, so it is essentially to collapse the @maven group, making the permission groups match the existence of a corresponding dev lists. [ ] +1 for the full proposal - collapse all groups (implies a vote for the next option if vote doesn't pass) [ ] +1 for the partial proposal - retain subproject access restrictions [ ] 0 abstain from vote [ ] -1 do not alter the current permissions +1. As Arnaud said, we're all adult here and can take the chance on people being granted access to the entire code base. We really need more people to keep up with patches and their own itches, in particular when it comes to the plugins. We still have the opportunity to stop releases if they're not to the expected quality and keep working on the code base until it has the sufficient code quality. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r493534 - in /maven/plugins/trunk/maven-repository-plugin/src: main/java/org/apache/maven/plugins/repository/BundleCreateMojo.java test/java/org/apache/maven/plugins/repository/BundleC
Jason van Zyl wrote: On 7 Jan 07, at 12:30 PM 7 Jan 07, Fabrizio Giustina wrote: On 1/7/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 6 Jan 07, at 1:45 PM 6 Jan 07, [EMAIL PROTECTED] wrote: MREPOSITORY-2 project.scm.connection should not be required for bundle-create Why not? the project could not have a public repository, there are projects that only distribute binary/source jars without having an accessible scm at all. Can you give me an example of an OSS project submitting something to the central repository that doesn't have a public repository? How can you operate as an OSS project without a public repository? There are already several examples on that there. There is nothing in the OSS licenses that requires the source to be publicly available all the time, only the parts that you distribute. It doesn't make sense that repository:bundle-create require it to work, also because it's not really useful for users It's definitely useful for users to have the location of the source repository. Especially from IDEs if you grab a remote POM and want to create a project. (on the other hand license info was not mandatory, and that's something that can always be filled and that is definitively useful). The license file was, but the element being specified is better. Some form of license information was mandatory. I'm -1 to letting people submit without that information. Your justification is unsatisfactory as is. How about just having a big, fat warning about the POM not having SCM information? Then it's up t the uploader to take action if it *should* have SCM (like all apache, codehaus and sourceforge projects should have). -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum and svn connections
Wendy Smoak wrote:
The ASF Subversion server limits connections to 10 per IP address, and
with several ASF projects loaded up, Continuum is regularly exceeding
this limit.
I'm not sure if it's just opening too many, or if they aren't getting
closed properly, or what, but it ends up meaning that I can't connect
to svn from anything here until they time or or otherwise go away.
Typically, I see 10 connections in CLOSE_WAIT and one in SYN_SENT.
I've had two versions of Continuum running all week, and this just
started today (with r493025.)
I would guess that something is using URL.openInputStream() without
closing it in a finally{}.
--
Trygve
Re: WebDAV
Brett Porter wrote: The first time anyone fixes/changes anything in archiva, this will start getting harder to keep in sync, so we should do it sooner rather than later. I'll try to get some time to do it sooner than later, but can't promise anything. One question though - if it was based on Archiva why were all the licenses removed? Because it was only based on the ideas of the Archiva, so I felt I rewrote most of it. If I've done something wrong in that I'm sorry. I'll put back the ASL (as it was supposed to be all the time), but not sure who I should give the copyright. -- Trygve
Re: [vote] Establish a list of emeritus committers
Brett Porter wrote: Hi, Vote to operate as - requiring 2/3rds of the PMC to vote (13), with a majority within those votes for it to pass (ie, add them all and if the result is 0). Other votes would be welcome with reasons as advisory, but not binding. - Votes can be changed at any time before result is posted. - Vote is open for at least 72 hours, completing once enough have voted after that. I propose to establish a list of emeritus committers. - Someone can request to be made emeritus at any time they want - They will be listed as past members of the team (we will set up a special page for this), but have no karma. - An emeritus committer can request commit access again at any time they feel they can be active, and a vote will be held to accept them or not. - PMC members will not be made emeritus (unless they chose to stand down from the PMC). To start with, anyone who hasn't committed in 12 months will be made automatically emeritus. ie, this vote is to make the following people emeritus: - Pete Kazmier - Peter Lynch - Tom Copeland - Dan Diephouse - Alex Karasulu - Ben Walding - Daniel Rall - David Eric Pugh - Geir Magnusson Jr - Kasper Nielsen - Kurt Schrader - Stephane Mor - Bob McWhirter - Peter Donald - Peter Royal - Johnny R. Ruiz III +1 -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Emeritus committers removing inter-project commit restrictions
Brett Porter wrote: Sorry, just catching up on a couple of these now. Myself and Brett can flip SVN bits and generally one of us is around. And if you're a committer you've already got access to sandboxes. I'm not really talking about the relative difficulty of granting access. Yes, that's quick. Though a vote is first required. And at what point do you ask for commit? Or do you wait for someone to nominate you? Does everyone know the current permissions structure enough to be able to do that effectively? Or are they just going to assume someone is already a committer and not think about it? That someone could check in some code and deploy a snapshot without talking to anyone, which is a possibility with the free-for-all scenario, is not something I want to go have to fix. Anyone here can deploy a snapshot now, without checking it in or talking to anyone. So we have a disparity of permissions there (though that obviously can be fixed, too). We've had no cross-plugin barriers though some people obviously know more about some than others. How many times have we had a problem there? By the way, if such a thing occurred and was innocent, it's fixable - and it's just as likely to innocently happen by someone who does have permission. Sometimes people already working on the same thing disagree. And if it's malicious, then the fix is fairly easy too. Doesn't take long to remove all karma. There, in reality, are several little teams or networks. Many people are part of many of them but there are still boundaries to these networks and things like public acceptance by everyone on these little teams is actually the more socially acceptable path IMO. A simple vote is not onerous. You're right - and I trust people to be socially responsible. I have full karma, but I still come and ask before doing something on a new area that I'm not all that familiar with (like the recent stuff with the plugin parent POM). I expect everyone to behave the same way. I don't really expect to vote in a committer at all that won't play by those rules. And really, who is actually going to get turned down by such a vote? If it's just meant to be a social pat of the back, let's just do that. Hey, I'm going to fix a bunch of bugs in the webdav wagon. I know I haven't done anything on there before, but I need this to deploy. Nice work, go for it!. And if it happens to just be fixing a typo on the web site, then they can go for it and save everyone else the inconvenience. And it's not really a matter of not trusting people. People can be careless, or think what they doing is ok when they haven't looked at any existing plans, or they may just be socially awkward (which is definitely not impossible with a bunch of predominantly male programmers who sit in front of computers all day). I think the best way to bring someone into the group is with a visible show of acceptance from the group. And we've already done that to bring them into the project in the first place (and all those problems are equally applicable to the existing committers). I don't think building up walls inside the project is healthy. The current situation leads to discouraging situations more than encouraging situations. Part of the problem is that the real social boundaries don't map easily to the technological ones. For example, I think nobody would have an objection to Wendy editing documentation for the plugins. But the commit rights say she only has permission on the main site. If she decided to rewrite the clover plugin, I think Vincent would want to hear about it first :) So should we give her permission to all the various bits of documentation scattered throughout the trees, and the parent pom, but not other parts of the code? That'd be a mess in the configuration. So, we can either give her full access (and trust her to consult Vincent before rewriting his plugin), or as now require she submit patches to documentation. That has lead to the following situation (by my count): 5 unapplied patches from Wendy. 4 from Brian fox (and one that could have been taken care of quite quickly by him, but went unnoticed and was filed 3 times, wasting a bunch of time to sort out). 5 from Dennis (who has commit access, but is adhering to the social rule of not being familiar with it yet). 9 from Edwin, 2 from Andy, 1 from Milos. There are more, and there have been plenty in the past. More than 25 fixes going to waste - about 10% of all the patches we have. Basically, I think this stops things getting done, with no discernible advantage. If they're not sure, they're going to ask or keep submitting patches instead. If they're not sure and not going to do that, they don't belong here in the first place. Anyway, I'm calling the emeritus vote now, but would like to hear more on this. I think I agree with you now, Brett. We've given them karma once, why should we have to ask the same questions,
Re: the verifier and idea on Mac
Stephane Nicoll wrote: Hi all, First all an happy new year to everyone! I have an issue with my brand new Mac ( :))) ). The EAR plugin tests do not work when ran within IDEA (stacktrace below). The funny thing is that it does not work either when I run mvn from IDEA using the external tools functionnality. When ran from the command line, everyting works OK. M2_HOME and the path to mvn is specified in /etc/profile [snip] Caused by: java.io.IOException: mvn: not found [snip] This is because mvn is not in IDEA's PATH. --- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: voting on parent POMs
Brett Porter wrote: Hi, Some time back, I think we agreed to vote to release parent POMs too. Am I misremembering, or have we just lost the habit? I'd like to get back to that, as I've lost track of the reasons for each release and don't necessarily agree with one of the last ones (need further clarification, question to follow). WDYT? Definitely, they are as important as the plugins. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Emeritus committers removing inter-project commit restrictions
Brett Porter wrote: Hi, I'd like to propose two things: 1) Establish a list of emeritus committers. 2) Remove inter-project commit restrictions The first does not depend on the second. But I think the second does depend on the first. I would like to put each to a separate vote once all the pros and cons have been gathered from this discussion. I'd expect each vote to operate as requiring 2/3rds of the PMC to vote (12), with a majority of +1's within those votes for it to pass. Other votes would be welcome with reasons as advisory, but not binding. * Emeritus committers Someone can request to be made emeritus at any time they want (usually because they have moved on to other things, or just don't have the time). They will be listed as past members of the team, but have no karma. An emeritus committer can request commit access again at any time they feel they can be active, and a vote will be held to accept them or not. To start with, anyone who hasn't committed in 12 months will be made automatically emeritus. PMC members will not be made emeritus (unless they chose to stand down from the PMC). +1. * Removing restrictions The list of groups we have can be seen here: http://people.apache.org/~jim/projects.html. There are a lot. (the page is currently down, unfortunately) Currently, only PMC members can commit to anything. Rather than using this technological boundary, which can be a hindrance, I'd rather use a social boundary. That is, if you don't quite know what you are doing but would like to try something new, or want to make a big change in something you don't regularly commit to - ask first. Perhaps create a branch and have the regular committers review it first. -0, I like the fact that people are forced to ask before doing stuff, but OTOH it's a bit annoying having to wait a couple of days if you have a couple of quick fixes for a product that you can fix *now*. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Doxia Velocity Render Module
Henning P. Schmiedehausen wrote: This is the fruit of some toying with Doxia, Plexus, the various different ways to write annotations, Plugins and some general maven hacking. And a lot of frustration about the state of general and specific Maven 2 documentation. It allows you to do things like http://svn.apache.org/viewvc/db/site/templates/whoweare.xml?revision=227393view=markup with Xdoc and Apt in Maven 2. Docs are at http://people.apache.org/~henning/velocity-doxia-renderer/ Get the source from http://svn.apache.org/repos/asf/velocity/site/doxia-velocity-renderer/ Comments very much appreciated. Please send me a Cc, I do not really read the maven lists. Best regards Henning P.S.: I would still be interested in a way to access the Mojo API from an extension without going through a plugin and a singleton. P.P.S.: And I am interested why the maven-plexus-plugin does not know about fields in superclasses. The Mojo packager obviously does. It should work just fine as long as the source code is available, just like the Mojo processor, IIRC there are even tests covering that. Could you please include a sample set of source files and I'll fix the issue ASAP. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r489248 - /maven/shared/trunk/maven-plugin-testing-tools/src/main/java/org/apache/maven/shared/test/plugin/PluginTestTool.java
[EMAIL PROTECTED] wrote: Author: jdcasey Date: Wed Dec 20 18:21:05 2006 New Revision: 489248 URL: http://svn.apache.org/viewvc?view=revrev=489248 Log: Modifying to delete the test version of the plugin from the target directory after it's installed in the test-time local repo. Modified: maven/shared/trunk/maven-plugin-testing-tools/src/main/java/org/apache/maven/shared/test/plugin/PluginTestTool.java Modified: maven/shared/trunk/maven-plugin-testing-tools/src/main/java/org/apache/maven/shared/test/plugin/PluginTestTool.java URL: http://svn.apache.org/viewvc/maven/shared/trunk/maven-plugin-testing-tools/src/main/java/org/apache/maven/shared/test/plugin/PluginTestTool.java?view=diffrev=489248r1=489247r2=489248 == --- maven/shared/trunk/maven-plugin-testing-tools/src/main/java/org/apache/maven/shared/test/plugin/PluginTestTool.java (original) +++ maven/shared/trunk/maven-plugin-testing-tools/src/main/java/org/apache/maven/shared/test/plugin/PluginTestTool.java Wed Dec 20 18:21:05 2006 @@ -133,6 +133,8 @@ MavenProject project = projectTool.packageProjectArtifact( pomFile, testVersion, skipUnitTests, buildLog ); repositoryTool.createLocalRepositoryFromPlugin( project, localRepoDir ); + +project.getArtifact().getFile().delete(); Better use IOUtil here as you have to check the return value of delete() to make sure it was deleted. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Mark Hobson wrote: Hi there, Has anyone got any objections to adding a new 'pre-package' phase to the default lifecycle? This is required by goals such as tomcat:run-war which require package pre-processing (overlaying wars, etc.) but not necessarily the fully built archive. I would definitely +1 such a phase, it's something the appassembler most definitely need too. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please vote for Archiva logo
+1 for top right, the other ones are just too close to Continuum and BEA's logo [1] and the logo symbolizes the centralisation that Archiva is supposed to bring. (it would also have been a nice Maven symbol) [1]: http://www.bea.com/content/images/logo_bea_tl.gif -- Trygve From: Brett Porter [EMAIL PROTECTED] Date: 13 November 2006 10:34:20 AM To: archiva-dev@maven.apache.org Subject: Re: [vote] Archiva Logo Reply-To: archiva-dev@maven.apache.org List-Id: archiva-dev.maven.apache.org Message-Id: [EMAIL PROTECTED] Currently, we have eliminated Top Left. We have 9 votes (60%) for lower left, and 6 for top right. In addition, we have more committers in the TR camp. That seems a bit close for now, so I'm going to look for more votes. On the other hand, all the TR's second preferences were for LL, whereas LL's second preferences were for LR, not TR. Please feel free to vote if you haven't. I'm going to get the logos put into the site so that we have a better frame of reference. Cheers, Brett On 08/11/2006, at 12:43 PM, Brett Porter wrote: Hi, There seemed to be no major objections to the logos presented, so I'll turn this into a formal vote. Please vote [1] for the one you would like and [2] for your second preference, if you have one, and so on. Ideally, there will be a clear majority of first preferences. The lowest scoring choice will be eliminated and their second preference used, and so on to determine the most popular. http://people.apache.org/~brett/archiva_logo.gif Vote will close in 72 hours. [ ] Top Left [ ] Top Right [ ] Lower Left [ ] Lower Right I will count the feedback from these people already: Raphael (1 - Lower Left), Wendell (1 - Lower Left), Milos (1 - Lower Left, 2 - Lower Right), Henri (1 - Lower Left), Natalie (1 - Top Right), Jesse (1 - Top Right), Edwin (1 Top Right), Nicolas (1 - Lower Left). If you want to change your vote, just respond again. Cheers, Brett
Re: Obtaining Maven source code
Anirudh Chandrakant wrote: Hi, could you please tell me how i can obtain (download) the maven source code. The Maven 2 source repository is at [1]. [1]: http://svn.apache.org/repos/asf/maven/components/trunk/ -- Trygve
Re: Writing CM Synergy plugin for Maven
(In the future, do not set the Reply-To header for messages intended to be answered publicly) On Mon, 2006-08-14 at 17:57 +, Julien HENRY wrote: Hi, My next job (on september) will be to write a plugin for CM Synergy. I'm already an advanced user of Maven 2, and I have already used several scm (CVS, SVN and VSS). Could you give me some tips that will help me writing such a plugin? The best documentation to date is the existing source code which is pretty clean. Check out the source code from [1], copy one of the existing one (the svn provider for example) and start with that. [1]: https://svn.apache.org/repos/asf/maven/scm/trunk/ -- Trygve
Re: JPOX errors on startup
On Sat, 2006-08-12 at 05:18 -0700, Erik Bengtson wrote: I've downloaded continuum 1.3 and collected some errors from the first startup. If they are expected, IMO they should not be printed to the logs, unless DEBUG is enabled. I must say the first startup takes very long. Please let me know where I can help. 1- jvm 1| 2006-08-12 14:00:44,656 [WrapperSimpleAppMain] INFO SCHEMA - Initialising Catalog , Schema SA using SchemaTable auto-s tart option The Continuum code is not logging this, AFAIK it somewhere between JPOX and Derby. 2- org.codehaus.plexus.personality.plexus.lifecycle.phase.StoppingException: Error storing the Continuum configuration. This seems to be because of other JPOX issues that we're having. I remember Emmanuel or you had some clues on how to fix this earlier which I'm pretty sure will fix this issue too. 3 -- jvm 3| 2006-08-12 14:04:59,468 [WrapperSimpleAppMain] WARN RDBMS - Column BUILDDEFINITION.LATEST_BUILD_ID should not allow nulls b ut does. You can prevent nulls by specifying allows-null as false for the f ield in the MetaData Dunno, Emmanuel? Another issue I've looked into is the two minute (or 2x 1 minute) delay when starting up. IIRC you said it was because JPOX was validating the database, and that seems to be the cause but I haven't been able to stop JPOX from validating it. I've set the three properties to false, but it didn't help. I don't have the logs here but I can make a tarball illustrating the problem later. -- Trygve
Re: svn commit: r429342 - in /maven/continuum/branches/continuum-acegi/continuum-security/continuum-security-acegi/src/test/java/org/apache/maven/continuum/security/acegi/aspectj: AbstractMethodSecuri
On Mon, 2006-08-07 at 13:56 +, [EMAIL PROTECTED] wrote: Author: carlos Date: Mon Aug 7 06:56:43 2006 New Revision: 429342 [snip] +setContinuum( (Continuum) lookup( org.apache.maven.continuum.Continuum ) ); Here you should use Continuum.ROLE instead to make everything consistent. -- Trygve
Re: [VOTE] Rename repository manager
On Thu, 2006-08-10 at 09:57 +1000, Brett Porter wrote: Please vote for one of the following names: [ ] Archiva +1 -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getting sources into eclipse
Berndq wrote: Hi, is there an easy way to get maven sources into a eclipse java project? (getting all the source folders right) I'd like to use eclipse to browse the sources. Run mvn eclipse:eclipse and it should generate the .project and .classpath files for each project. Thaught that there where some .project and .classpath files in svn but I cannot find them anymore. That must have been a few years ago :) -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] A new name for the repository manager?
Fabrizio Giustina wrote: [EMAIL PROTECTED] could be ok, I don't think length is a problem. Anyway, I agree that finding a better name for reposiory manager would be nice... I'll start with a first proposal: what about Concierge? :) http://en.wikipedia.org/wiki/Concierge A concierge (French), in French apartment buildings, is an employee who lives on the premises and serves as a janitor and general caretaker. [...] In 19th century and early 20th century apartment buildings, particularly in Paris, the concierge, often a middle-aged woman, had a small apartment on the ground floor and was able to monitor all comings and goings. [...] Me like. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refinements on the Maven Site plugin's list based on the discussion on the mailing list
Pete Marvin King wrote: Hello All, I tried to categorize the plugins on maven site's plugin list based on the discussion on the mailing list. It would be great Seems like if you attach a html to the issue it will be rendered like a html page which I think is sufficient for you. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r426203 - in /maven/doxia/trunk/doxia-sandbox/doxia-book: ./ src/main/java/org/apache/maven/doxia/book/services/indexer/ src/main/java/org/apache/maven/doxia/book/services/renderer/ sr
Vincent Siveton wrote:
[snip]
These comments are pretty useless, I'd rather not sprinkle the code
with
obvious comments.
Agree but if no comment, nobody thinks to had comment, specially for
new and important updates. my2cents ;)
Not sure what you mean, please explain again.
We know that writing good and informative comments is hard and bad
comments are just a waste... My point is that a class without a
minimum of comments is likely to remain like this in the future:
nobody thinks or dares to add new comments.
For instance, the Sink interface and its implementations dont have a
lot of useful documentation even if several developers worked on it.
WDYT?
You can't compare the Sink interface which is one of the most important
interfaces in the entire Doxia product against obvious comments saying
the exact same thing as the method name.
I do agree that we need to improve our javadoc, but I do not think that
adding obvious comments is the way to go. I'd rather just take some time
and document the parts which are not ovious.
IMHO I think that Doxia needs to be review at large to add comment.
Agreed, we need to document the important parts.
yep
[snip]
+//
+//public void tableCaption()
+//{
+//type = TYPE_TABLE;
+//}
Any special reason for this other than you identing it by accident?
Well, it is not an accident: it is the Eclipse formatter with the
Maven Code Style
(http://maven.apache.org/guides/development/guide-m2-development.html)
Promise, I will try idea ASAP ;)
That has never been a standard that I can recall. Comment blocks always
start on column 1.
I know that it is not a standard! It is an Eclipse issue ;)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=34552
[snip]
I like these, they are separators between logical parts of the method.
It is not a Maven standard style thus I removed it. Is it for Doxia?
If yes, we need a developping guide.
They are very much a standard part of the Maven code, we (at least I)
use it all the time.
I will do
Will you put back the comments that was removed?
--
Trygve
Re: [discuss] A new name for the repository manager?
Brett Porter wrote: Hi, I was considering starting a vote for setting up separate discussion lists for the repository manager and was pondering what to call them. [EMAIL PROTECTED] seems just a bit too long. All the other parts - Continuum, Wagon, Doxia, Surefire, Archetypes - have a more interesting name (ok, so SCM is an exception). I wonder, should we give the repository manager a real name? Any thoughts? I wouldn't mind a better name like most of our products have, I'm sure Jason can come up with a few nice sounding names. If folks are happy to stick with Maven Repository Manager, are there any preferences for whether the lists should be mrm-*, repoman-*, repository-manager-*, or something else? +1 for repository-manager-* for the sake of consistency and that most mail clients completes the name after I've written repo. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r426635 - in /maven/doxia/site/src/books: example-book.xml example-book/aegis-binding.apt example-book/castor.apt example-book/jms-transport.apt
Vincent Siveton wrote: Background: bindings was used as id for a chapter and a section. Now, we create a chapter index page with id as filename. During the renderer execution, chapter index page is overrided by the section file so we need a unique id and more validation... Ok, now it makes sense. Thanks. -- Trygve
Re: Maven1 project converter
Emmanuel Venisse wrote:
oh yes :-)
We're old school Emmanuel, I still use the old version too often..
--
Trygve
Emmanuel
Brett Porter a écrit :
On 28/07/2006 7:27 PM, Emmanuel Venisse wrote:
/**
* @parameter
expression=${component.org.apache.maven.model.converter.Maven2Converter}
* @required
*/
private Maven1Converter converter;
or better:
/**
* @component
*/
private Maven1Converter converter;
-
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: [vote] Release Maven DOCCK plugin
Dennis Lundberg wrote: The DOCCK plugin has been a great help for us who have been working on updating the plugin documentation. The docs for it is in the standard format. I have published the site, but have not linked to it from the Maven site yet: http://maven.apache.org/plugins/maven-docck-plugin/ First off we need to decide what version number to use. I see two candidates here: [ ] 1.0, as its current version is 1.0-SHAPSHOT [ ] 2.0, to have all Maven 2 plugins use 2.x versions +1 for 1.0, 2.0 is only used for plugins that exists as Maven 1 versions. If it is required to have a beta version first, please voice your opinion about that. I'd be fine with releasing a beta as well. Release a beta first, we need to get it properly tested before it's finally released. I know it has been used on all of our plugins, but we do stuff in a certain way etc. Run it on all of the (released) Mojo plugins and I'm happy to release a 1.0. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r426618 - in /maven/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/module: xdoc/XdocSink.java xhtml/XhtmlSink.java
[EMAIL PROTECTED] wrote: Author: vsiveton Date: Fri Jul 28 10:55:37 2006 New Revision: 426618 URL: http://svn.apache.org/viewvc?rev=426618view=rev Log: o Changed itemFlag type to boolean instead of int thus no need to throw a RuntimeException Are you sure this will work? What happens when it's nesting items? -- Trygve
Re: Developed a RAD6 extention of maven-eclipse-plugin
Richard van Nieuwenhoven wrote: Hello, i developed a rad-6 maven plugin based on the eclipse plugin for a big customer who want's to use maven-2. It was developed because i could not find a rad-6.0 capable maven plugin that realy works. Stuff like this should probably be extensions to the Eclipse plugin instead of beeing embedded *in* the Eclipse plugin. That way other code generating Eclipse projects can use them more easily. I know Kaare has been wanting to add AspectJ support in the generated Eclipse files too. My customer allowed me to release the code, now my question is how to do it Create an issue under the eclipse plugin and attach the tarball there. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r426203 - in /maven/doxia/trunk/doxia-sandbox/doxia-book: ./ src/main/java/org/apache/maven/doxia/book/services/indexer/ src/main/java/org/apache/maven/doxia/book/services/renderer/ sr
Vincent Siveton wrote:
Hi Trygve,
I like your points :) My comments inside.
[snip]
+/**
+ * Default constructor
+ *
+ * @param sectionEntry
+ */
public BookIndexingSink( IndexEntry sectionEntry )
{
stack.push( sectionEntry );
}
These comments are pretty useless, I'd rather not sprinkle the code with
obvious comments.
Agree but if no comment, nobody thinks to had comment, specially for
new and important updates. my2cents ;)
Not sure what you mean, please explain again.
IMHO I think that Doxia needs to be review at large to add comment.
Agreed, we need to document the important parts.
[snip]
-//public void definedTerm()
-//{
-//type = TYPE_DEFINED_TERM;
-//}
-//
-//public void figureCaption()
-//{
-//type = TYPE_FIGURE;
-//}
-//
-//public void tableCaption()
-//{
-//type = TYPE_TABLE;
-//}
+//public void definedTerm()
+//{
+//type = TYPE_DEFINED_TERM;
+//}
+//
+//public void figureCaption()
+//{
+//type = TYPE_FIGURE;
+//}
+//
+//public void tableCaption()
+//{
+//type = TYPE_TABLE;
+//}
Any special reason for this other than you identing it by accident?
Well, it is not an accident: it is the Eclipse formatter with the
Maven Code Style
(http://maven.apache.org/guides/development/guide-m2-development.html)
Promise, I will try idea ASAP ;)
That has never been a standard that I can recall. Comment blocks always
start on column 1.
public void text( String text )
{
IndexEntry entry;
-switch( type )
+switch ( type )
{
case TITLE:
this.title = text;
@@ -137,15 +168,7 @@
// Sanitize the id. The most important step is to
remove any blanks
//
---
-String id = text;
-id = id.toLowerCase();
-id = id.replace( '\'', '_' );
-id = id.replace( '\', '_' );
-id = id.replace( ' ', '_' );
-
-//
---
-//
-//
---
+String id = HtmlTools.encodeId( text );
Ah, I knew it was somewhere.
It is a new method ;)
[snip]
{
if ( !context.getOutputDirectory().mkdirs() )
{
-throw new BookDoxiaException(
-Could not make directory: +
context.getOutputDirectory().getAbsolutePath() + . );
+throw new BookDoxiaException( Could not make
directory:
++
context.getOutputDirectory().getAbsolutePath() + . );
}
}
-//
---
-//
-//
---
-
I like these, they are separators between logical parts of the method.
It is not a Maven standard style thus I removed it. Is it for Doxia?
If yes, we need a developping guide.
They are very much a standard part of the Maven code, we (at least I)
use it all the time.
[snip]
+
+//
---
// Private
//
---
+/**
+ * Render the book, ie the book index and all chapter index
+ *
+ * @param book
+ * @param context
+ * @throws BookDoxiaException if any
+ */
private void renderBook( BookModel book, BookContext context )
throws BookDoxiaException
{
-//
---
-// Render the book index.xml page
-//
---
-
File index = new File( context.getOutputDirectory(),
index.xml );
try
@@ -86,12 +137,6 @@
}
//
---
-// Render the index.html files for each chapter
-//
---
-
-// TODO: Implement
-
-//
---
// Render all the chapters
//
---
Ditto here about the commends. They explain the flow in the code.
IMHO javadoc should provide it ;) developing guide...?
No, javadoc is not the same thing as inline comment. This is
Re: svn commit: r426635 - in /maven/doxia/site/src/books: example-book.xml example-book/aegis-binding.apt example-book/castor.apt example-book/jms-transport.apt
[EMAIL PROTECTED] wrote: Author: vsiveton Date: Fri Jul 28 11:13:01 2006 New Revision: 426635 URL: http://svn.apache.org/viewvc?rev=426635view=rev Log: o Fixed typo in the example-book o Fixed unique id for chapter/section Modified: maven/doxia/site/src/books/example-book.xml maven/doxia/site/src/books/example-book/aegis-binding.apt maven/doxia/site/src/books/example-book/castor.apt maven/doxia/site/src/books/example-book/jms-transport.apt Modified: maven/doxia/site/src/books/example-book.xml URL: http://svn.apache.org/viewvc/maven/doxia/site/src/books/example-book.xml?rev=426635r1=426634r2=426635view=diff == --- maven/doxia/site/src/books/example-book.xml (original) +++ maven/doxia/site/src/books/example-book.xml Fri Jul 28 11:13:01 2006 @@ -4,7 +4,7 @@ titleXFire User Manual/title chapters chapter - idbindings/id + idbind/id titleBindings/title sections section Why? The id and title should be similar. -- Trygve
Re: svn commit: r426618 - in /maven/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/module: xdoc/XdocSink.java xhtml/XhtmlSink.java
Vincent Siveton wrote: 2006/7/28, Trygve Laugstøl [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: Author: vsiveton Date: Fri Jul 28 10:55:37 2006 New Revision: 426618 URL: http://svn.apache.org/viewvc?rev=426618view=rev Log: o Changed itemFlag type to boolean instead of int thus no need to throw a RuntimeException Are you sure this will work? What happens when it's nesting items? I'm not sure what you mean. BTW here is a small example, hope this helps http://people.apache.org/~vsiveton/MSITE-153/ Sorry, I don't understand the relation here. Isn't the itemFlag supposed to be incremented and decremented when you nest more item lists? Like this: ol li ol li/li li/li /ol /li li ol li/li li/li /ol /li /old -- Trygve
Re: svn commit: r425887 - /maven/components/trunk/maven-model-converter/src/main/java/org/apache/maven/model/converter/Maven1Converter.java
[EMAIL PROTECTED] wrote: Author: evenisse Date: Wed Jul 26 15:41:10 2006 New Revision: 425887 URL: http://svn.apache.org/viewvc?rev=425887view=rev Log: Create output directory Modified: maven/components/trunk/maven-model-converter/src/main/java/org/apache/maven/model/converter/Maven1Converter.java Modified: maven/components/trunk/maven-model-converter/src/main/java/org/apache/maven/model/converter/Maven1Converter.java URL: http://svn.apache.org/viewvc/maven/components/trunk/maven-model-converter/src/main/java/org/apache/maven/model/converter/Maven1Converter.java?rev=425887r1=425886r2=425887view=diff == --- maven/components/trunk/maven-model-converter/src/main/java/org/apache/maven/model/converter/Maven1Converter.java (original) +++ maven/components/trunk/maven-model-converter/src/main/java/org/apache/maven/model/converter/Maven1Converter.java Wed Jul 26 15:41:10 2006 @@ -267,6 +267,8 @@ outputdir = basedir; } +outputdir.mkdirs(); All File.mkdirs() calls has to be wrapper with a if test to see if it was actually created. Silly mkdirs() returning true/false instead of throwing an exception as everything else. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r425905 - /maven/components/trunk/maven-model/maven.mdo
[EMAIL PROTECTED] wrote: Author: jdcasey Date: Wed Jul 26 16:37:55 2006 New Revision: 425905 URL: http://svn.apache.org/viewvc?rev=425905view=rev Log: Adding codeSegment for object identity to Plugin class. Those can be generated. See [1] for an exampe xml on how to identify fields as a part of the bean id. [1]: http://svn.codehaus.org/modello/trunk/modello-core/src/test/resources/models/simple.mdo -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r425406 - in /maven/plugins/trunk/maven-surefire-plugin: ./ src/main/java/org/apache/maven/plugin/surefire/ src/site/ src/site/apt/ src/site/apt/examples/ src/site/fml/
Allan Ramirez wrote: Hi Trygve, done. Thanks! Can you include the message here aswell? -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
