[vote] release maven-release-1 parent and maven-release-manager-1.0-alpha-1
With maven-scm having its latest release underway, the final linchpin in getting alpha releases of continuum up and running is the maven-release and maven-release-manager. So I am calling a vote to get the maven-release parent pom released and the maven-release-manager which the continuum-release module makes use of as well as the maven-release-plugin which is _not_ under the purview of this vote. In Staging Repo: http://people.apache.org/~jmcconnell/org/apache/maven/release Tags: http://svn.apache.org/repos/asf/maven/release/tags/ Anyway, lets try this and see how it goes: 72 hrs +1/0/-1. Cast away! :) jesse +1 from me... -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-plugin-testing-harness
+1 On 4/13/07, Arnaud HERITIER [EMAIL PROTECTED] wrote: +1 Arnaud On 13/04/07, Carlos Sanchez [EMAIL PROTECTED] wrote: anyone? On 4/10/07, Carlos Sanchez [EMAIL PROTECTED] wrote: It adds some stub method implementations from previous releases Right now it's 1.0-beta-2 but has been pretty stable during last year, so i'd suggest releasing 1.0 and whatever is added in the future go to 1.1, 1.2, ... https://svn.apache.org/repos/asf/maven/shared/trunk/maven-plugin-testing-harness 527389 -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-release-1 parent and maven-release-manager-1.0-alpha-1
Summary: 6 binding +1 (jesse, emmanuel, jdcasey, snicoll, arnaud, vsiveton) I'll get this moved over and synced out today. thanks! next up, continuum 1.1 alpha 1 On 4/15/07, Stephane Nicoll [EMAIL PROTECTED] wrote: On 4/15/07, Max Bowsher [EMAIL PROTECTED] wrote: Stephane Nicoll wrote: On 4/14/07, Max Bowsher [EMAIL PROTECTED] wrote: Too late for this release, but could someone take a look at MRELEASE-137 so it gets into the next one? It's a trivial one-liner fix. The attached patch is for maven-release-plugin, but the relevant class has since moved into maven-release-manager. It's obvious how to forward port the single change to the new code. The change does not seem that trivial to me. A potential IndexOutOfBoundsException might be trhown. Jason is the assignee but i'll try to have a look. The current code calls: list.get( 0 ) the fix is to change that to: list.get( list.size() - 1 ) Surely the only way the second one could cause an IOOBE is if the list is empty, in which case the current code would also IOOBE? I'm missing coffee. Forget it :) Max. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Not able to build maven-release
faultArtifactResolver.java:73) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:526) ... 19 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to downl oad the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(Def aultWagonManager.java:324) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:185) ... 21 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Apr 19 18:20:20 EDT 2007 [INFO] Final Memory: 1M/2M [INFO] -- View this message in context: http://www.nabble.com/Not-able-to-build-maven-release-tf3610157s177.html#a10088306 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
might as well just use this thread... I have continuum 1.1 alpha 1 staged now...but I have one concern about calling a vote on this and making it official... Its kinda big (16M war, 25M plexus app) and I still don't really feel comfortable releasing something like continuum as an alpha into the main repositories. its currently staged at: http://people.apache.org/~jmcconnell/continuum What do you guys think? just call a vote on it and get it pushed into the wild or can we just do the alpha's like this through the staging setup? jesse On 3/30/07, Brett Porter [EMAIL PROTECTED] wrote: On 31/03/2007, at 6:50 AM, Emmanuel Venisse wrote: I'm ok for a timestamped version, but we can release the release manager too, without the plugin because it isn't ready and I want the new Maven-SCM in it. We're not set up to have snapshots in place permanently, so I don't think we should use a timestamped one. I'd agree with releasing just the shared release component. The pb is that release-manager use maven-scm 1.0-SNAPSHOT, we can use 1.0-beta-4 because the release manager doesn't use new code of maven-scm but we won't have maven-scm fixes. Or we can use a timestamped version of Maven-SCM too. If we choose the timestamped version of Maven-SCM, Continuum need to use it. I think we could cut another beta of Maven SCM now with the recent fixes before you push towards 1.0 as discussed on that list. Cheers, Brett -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] release maven-source-plugin 2.0.3
+1 On 4/21/07, Vincent Siveton [EMAIL PROTECTED] wrote: +1 Vincent 2007/4/21, Brian E. Fox [EMAIL PROTECTED]: +1 -Original Message- From: Stephane Nicoll [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 10:49 PM To: Maven Developers List Subject: [vote] release maven-source-plugin 2.0.3 Hi, I'd like to release the maven-source-plugin 2.0.3 The staging bits are available here: http://people.apache.org/~snicoll/maven-staging/repo/org/apache/maven/plugins/maven-source-plugin/2.0.3/ The release notes: ** Bug * [MSOURCES-6] - Sources plugin ignores resource includes/excludes * [MSOURCES-12] - size of source jar grows and grows ** Improvement * [MSOURCES-11] - When source plugin is used, it should make sure it is invoked during install Vote open for 72hours. My +1 Stéphane - 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] -- jesse mcconnell [EMAIL PROTECTED]
Re: XML RPC security
I am hoping to get a couple of authn and authz web services running in
redback this week, once I finish up the role profile refactor and
clean up, I want to wack out a webservice and then start getting
continuum integrated to using the new redback setup.
sounds like that would work perfectly for this xml-rpc stuff in continuum.
rahul, planning on using xfire until the apache CXF stuff gets it
first release out of the incubator...that sound good?
jesse
On 4/30/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Maybe, but I can't find it.
Emmanuel
Rahul Thakur a écrit :
I thought there was something similar to this that exists in Redback?
Rahul
- Original Message - From: Emmanuel Venisse
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, April 28, 2007 12:37 AM
Subject: Re: XML RPC security
I think it's best solution. With a token, we don't have login/password
over the network for each request.
XmlRpcService
String login( username, password ) //return a token
{
tokenManager.login( username, password );
}
Object method1( token, params ) //null token for guest user or a
getGuestToken() method that will return it
{
User user = tokenManager.getUser( token );
...
}
Object method2( token, params )
{
...
}
TokenManager
String login( username, password ); //return a token
User getUser( token )
The TokenManager can be a plexus component with a default
implementation for redback.
wdyt?
Emmanuel
Emmanuel Venisse a écrit :
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'.
Thoughts?
Rahul
--
jesse mcconnell
[EMAIL PROTECTED]
Re: Complete: trunk version upgraded to 1.0-alpha-1-SNAPSHOT
\o/ nice job :) On 5/1/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: The merge is complete. Trunk is now on version 1.0-alpha-1-SNAPSHOT using the former database branch. Old trunk is now located in https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-0.9 - Joakim Joakim Erdfelt wrote: Steps 1-4 are now complete. Working on Step 5 (make version in trunk 1.0-alpha-1-SNAPSHOT) now ... - Joakim Joakim Erdfelt wrote: Ok. Here's the vote breakdown. option A - Make the branch the new trunk. * Emmanuel Venisse * Arnaud Heriter * Nicolas De Loof * Jesse McConnell * Brett Porter * Wendy Smoak option B - Merge the branch into the existing trunk. * Maria Odea Ching option C - Do not merge the branch into trunk. * (n/a) Looks like option A wins! The current plan 1) Identify the changes since the branch has been made. Branch was created on March 15, 2007 - on revision 518676 2) Merge in changes made on trunk since branch into the branch. 3) Rename the current trunk as branch-0.9 4) Rename the archiva-jpox-database branch as the new trunk. 5) Set the versions in the trunk to 1.0-alpha-1-SNAPSHOT 6) Announce completion of merge to archiva-dev 7) Continue working on admin screens. 8) Once admin screens are stable, get the ball rolling on a 1.0-alpha-1 release. - Joakim Erdfelt -- jesse mcconnell [EMAIL PROTECTED]
Re: Involvement for a new request
neither of those are specifically on the roadmap for development, but having said that if you were you take a look and implement them we would be more then happy to factor them into continuum :) the thing to do to start would be to probably log them as issues in jira, maybe kick out some thoughts on implementation on this mailing list and get some patches into jira. also feel free to hop on irc and ask any questions you might run up against. continuum makes use of a number of components that exist in plexus, namely the taskqueue stuff which would probably require some work to implement that sort of behavior.. would be great to hear more on what your thinking! jesse On 5/15/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: Hi, We are using Continnum at my company and we had moved to it from Anthill pro. We are quite happy with continnum but there are a couple of features that were in AntHill that are missing from Continnum. The 2 features we are interested in the most are: 1- Ability to change the order of queued builds. 2- Grouping of projects according to their build status. A project that is currently building will be moved to the top, projects that are queued to build are grouped together and projects that are not queued to build are grouped together. My question is if these 2 features are planned for future releases of continnum, and if not then we are interested in implementing the features ourselves and submit the changes as a patch if other people are interested. Thanks, Bashar -- jesse mcconnell [EMAIL PROTECTED]
Re: Archiva r538691 not working
I just updated redback to the 10.2.1.6 derby and tried out the example app and it worked fine I will commit the update and push new snapshots of the relevent pieces, might be something about having multiple versions of derby floating around jesse On 5/17/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/16/07, Wendy Smoak [EMAIL PROTECTED] wrote: I noticed that the Archiva build downloaded Derby 10.2.1.6. Has Redback also been upgraded? I remember someone having trouble with Continuum/Archiva/Redback on a Derby version other than 10.1.3.1. Thinking that there may have been changes in Redback, I did a clean build at r6468, then re-built Archiva. I get the same ArrayIndexOutOfBoundsException stack trace, followed by INFO | jvm 1| 2007/05/16 22:44:43 | 2007-05-16 22:44:43,312 [SocketListener0-1] ERROR JPOX.RDBMS.Schema - An exception was thrown while adding/validating class(es) : No current connection. This one is also from derby - jpox - redback in the stack trace. (See the log files linked in my first message.) -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: [VOTE] Release maven-artifact-converter 2.1-alpha-1 / maven-transaction 1.0-alpha-1
+1, maybe just under the wire! On 5/25/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: Greetings! I'd like to release the following 2 maven shared modules. maven-artifact-converter - 2.1-alpha-1 svn:: https://svn.apache.org/repos/asf/maven/shared/trunk/maven-artifact-converter tag:: https://svn.apache.org/repos/asf/maven/shared/tags/maven-artifact-converter-2.1-alpha-1 maven-transaction - 1.0-alpha-1 svn:: https://svn.apache.org/repos/asf/maven/shared/trunk/maven-transaction tag:: https://svn.apache.org/repos/asf/maven/shared/tags/maven-transaction-1.0-alpha-1 You can find the staged version of these modules at http://people.apache.org/~joakime/stage/maven_shared_repo/ So, let's try 72h +1/+0/-1. Please cast your votes! Here my +1 -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Maven PMC welcomes Wendy Smoak
\o/ On 5/28/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: Congrats! and Welcome! -Joakim Brett Porter wrote: Hi all, The Maven PMC has voted to add Wendy Smoak to the PMC. Please join me in welcoming her! Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Change project names for M1 plugins in JIRA
+1 On 5/30/07, Brian E. Fox [EMAIL PROTECTED] wrote: +1 -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 30, 2007 1:01 PM To: Maven Developers List Subject: Re: [proposal] Change project names for M1 plugins in JIRA +1 On May 30, 2007, at 11:27 AM, Dennis Lundberg wrote: Hi We get some JIRA issues for the M1 plugins that really belongs to the M2 plugins. To help get these issues into the correct JIRA project from the start, I propose that we change the names of the JIRA projects for M1 plugins. From maven-idea-plugin to Maven 1.x IDEA Plugin. Note: for the M2 plugins we use names like Maven 2.x IDEA Plugin. I am willing to do the actual changes if you like this proposal. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[released] continuum-1.1-alpha-2
Highlights are:
* revamped xml-rpc support
* converted to use rebranded plexus-security, aka redback
* continuum maven plugin
* many bug fixes and ui improvements.
You can grab the latest release from:
http://maven.apache.org/continuum/download.html
Next up we are going to have another alpha release in a month, or
ideally a beta release that is feature complete for this version
around the beginning of July.
Anyway, below is the jira release notes for this release.
Release Notes - Continuum - Version 1.1-alpha-2
** Bug
* [CONTINUUM-620] - Changes section in Continuum build result and
build e-mail only show blank columns and file names
* [CONTINUUM-684] - Access to Continuum using XML-RPC is not authenticated.
* [CONTINUUM-1229] -
com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Invalid default
value for 'SCM_USE_CACHE'
* [CONTINUUM-1269] - Recforing of the XMLRPC server, must be a
servlet on the same port used by the webapp instead of a specific port
* [CONTINUUM-1275] - Project Group Name that contains only spaces
can be added.
* [CONTINUUM-1276] - Error in editing the Project name using spaces only
* [CONTINUUM-1282] - Adding or editing a Project Build Definition
can accept spaces in pom file name
* [CONTINUUM-1289] - Sorting Usernames in Build Management's
Project Group member list does not work in Firefox 2
* [CONTINUUM-1290] - Project ID is not validated when adding a Project Group
* [CONTINUUM-1292] - Error when clicking build icon in Project
Build Definitions summary
* [CONTINUUM-1293] - Hitting 'Add' button repetitively in adding
an Ant, Shell and Schedule using empty string only accumulates
validation prompts
* [CONTINUUM-1294] - Adding a Schedule, Ant/ Shell Projects can
accept spaces
** Improvement
* [CONTINUUM-1035] - Dependent builds not triggered via XMLRPC
* [CONTINUUM-1186] - Application should unpack to continuum-${version}
* [CONTINUUM-1297] - update to redback from plexus-security
** New Feature
* [CONTINUUM-683] - Implement a ping service that XML-RPC
clients can use to test connection.
** Task
* [CONTINUUM-1242] - Update Continuum Model
--
jesse mcconnell
[EMAIL PROTECTED]
Re: LDAP-Module for Continuum
could you make that apache license? then you can add it to issue http://jira.codehaus.org/browse/PLXREDBACK-74 and I'll take a look-see, I have been kicking around different ways to use ldap so it will be nice to see what you have :) jesse On 6/5/07, David Goemans [EMAIL PROTECTED] wrote: Hi, I've written a LDAP-Module for User-Management in Continuum (Plexus-redback). This has already worked fine. But it doesn't work with the actual trunk. I think something has changed with redback-configuration. I think a LDAP-Module for Continuum were a good feature and my company is willing to contribute it under GPL-License. David -- jesse mcconnell [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.7
+1 working for me so far On 6/13/07, LAMY Olivier [EMAIL PROTECTED] wrote: (non-binding) +1 (works fine on corporate builds). -- Olivier -Message d'origine- De : Jason van Zyl [mailto:[EMAIL PROTECTED] Envoyé : mercredi 13 juin 2007 07:13 À : Maven Developers List Objet : [VOTE] Release Maven 2.0.7 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/ 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] This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. -- Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.7 (take 2)
+1 On 6/19/07, Arnaud HERITIER [EMAIL PROTECTED] wrote: +1 Arnaud On 19/06/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: +1 How can I not vote +1? After all, according to the META-INF/MANIFEST.MF in the maven-core-2.0.7-uber.jar I built it. Niggle: It still feels wrong to have the maven-core-2.0.7-uber.jar have a LICENSE.txt in it's root that says it's a GPL'd application. - Joakim 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/ 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] -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - [EMAIL PROTECTED] www.octo.com | blog.octo.com .. ASF - [EMAIL PROTECTED] www.apache.org | maven.apache.org ... -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
On 6/26/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 25 Jun 07, at 7:11 PM 25 Jun 07, John Casey wrote: I like this approach, and I think it's just a slightly more detailed version of what some of us are already trying to do when we put together major new pieces for Maven. I agree with Eric that any API or behavioral change should probably follow this process, basically anything that could change what the user experiences. Yah, really just to surface the information. I know that there are only a few of us know where everything is because we look at it everyday but the casual contributor wouldn't have a chance. I think this really facilitates contribution. Someone who has a particular need can see if there is anything vaguely related to what he needs. agreed, so much of this material been beat around on irc and the back rooms of sleazy gin joints around the world...its good to get it all formally pulled into one area.. What would be the mechanism for ranking these in terms of priority or popularity or is that an concept we don't want to apply at this phase? My primary concern would be that given the wide variety of communication channels that maven folks operate under is this material becoming old or stale. Wiki's are notoriously easy to let languish. There has to be a concerted effort to make one place be the final resting place of all this sort of information. Its super easy to pay lipservice to this, 'oh, I'll just have the conversation on irc, or the mailing list and go back and update that wiki page later' and not follow through... of course, my stated primary concern there doesn't offer a better solution or alternative...just stating the obvious a bit anyway, +1, I like it :) -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Migrate ArchetypeNG to Apache commit privs for Raphael
+1 and another, very cool On 6/29/07, Jason van Zyl [EMAIL PROTECTED] wrote: Great, that's 4 PMC members already so people can continue to comment but I'll get Raphael to send in a CLA, and adjust the code for Apache. On 28 Jun 07, at 11:28 PM 28 Jun 07, Jason van Zyl wrote: Hi, After a fews weeks of sorting out some niggly details the new code new by default will produce a functional archetype without user intervention, and projects can be generated with the old and new archetype plugins. I asked that Raphael make some additions which generate the old and new descriptors so that anyone who had nailed down versions of their plugins by turning off updates will still be able to use new archetypes with the plugin they have on hand. You can still optionally enter interactive mode and the code is working well from the users perspective. The code can be refactored incrementally but will be a big improvement for users. I think Raphael has done a very good job and I think it's now ready to bring over here. I've been using the code for the last week trying it out with a Maven integration test archetype and it's working well. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CONTINUUM-1226
ya, I would agree with you emm, better get it done in the short term for beta-1.. jesse On 7/4/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi, I looked today at CONTINUUM-1226 and I confirm it doesn't work and it won't work without a DB schema change. To fix it, we must attach the build definition to the build result and remove the build result from the build definition (lastBuildId) that is totally wrong since a build definition can be a group build definition. With the build definition attached to the build result, we'll can find all scm changes since latest execution of the current build definition on the current project and multiple build definitions on a project will work. I think this DB schema change must be done before the release of 1.1-beta-1, so the migration between betas will be easier Emmanuel -- jesse mcconnell [EMAIL PROTECTED]
Re: [VOTE] Graduate maven-patch-plugin from sandbox and release version 1.0
+1 would like to note, that the first version would be useful on pre-shaded maven versions using p-u 1.1 and we have it ready to release again using later versions of p-u and the maven 2.0.6+ versions that will have more bullet proof bash shell support. On 7/6/07, John Casey [EMAIL PROTECTED] wrote: Hi all, Jesse and I have been working on a patch plugin that I migrated over from mojo.codehaus.org into the ASF sandbox, and we feel it's ready for a release. I've prepared the documentation for a code grant on this project, and all the appropriate information should be committed in the plugin directory. The plugin is stable, has decent documentation, and even an integration-test suite. Therefore, I'd like to call a vote to graduate the patch plugin from the Maven sandbox, and do a 1.0 release. Please +1/+0/-1. I'll let this go for 72 hours. The release is staged at: http://people.apache.org/~jdcasey/stage/repo (repository) http://people.apahce.org/~jdcasey/stage/sites/maven-patch-plugin (site) Here's my +1. Thanks to Jesse for helping me get the plugin to this point. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven Shared JAR component 1.0
+1 On 7/9/07, John Casey [EMAIL PROTECTED] wrote: +1 -john On Jul 4, 2007, at 5:17 AM, Brett Porter wrote: This component is used in the project-info-reports plugin (and is a prereq to its next release) and analyses JAR files for Maven information and general Java class information. Tag: https://svn.apache.org/repos/asf/maven/shared/tags/maven- shared-jar-1.0 Staging Repo: http://people.apache.org/~brett/stage-repo/ Website/documentation: http://maven.apache.org/shared/maven-shared- jar/ [ ] +1 [ ] 0 [ ] -1 72 hours go! Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum and minimum JDK requirement
just fyi, we are working on getting that profile enabled version released in the next couple of weeks jesse On 7/10/07, Brett Porter [EMAIL PROTECTED] wrote: On 11/07/2007, at 10:32 AM, Joerg Heinicke wrote: Hello guys, we had an issue recently with Continuum on Cocoon and continuous integration which fails to check JDK 1.4 compliance of Cocoon's code base since Continuum itself is running with a JDK 5 (in that particular case it was usage of ThreadLocal.remove() [1]). I found the thread about raising the minimum JDK for Continuum where exactly such issues where foreseen [2]. The binding problem is a relatively small number of cases that can probably be avoided in your code. Accidentally using JDK 5 methods is something that comes up frequently and you should certainly regularly build on 1.4 to check. Brett talked about the possibility to fork builds with Continuum [3]. Continuum always forks builds. However, controlling the JDK it used was not easy. I do believe profiles support will be in the next release and will make it easy. Putting it to the extremes there might even be a JDK 1.4 project using enum keyword which should be build with Continuum. If the latter requires JDK 5 is it possible though to build that project? Setting the correct -source will take care of that. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Database model change for beta-1
null value seems to be fine, I'll commit and try things out on the zone On 8/1/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: I think null value will be enough. I think we'll need to test the null value in the UI but it isn't a problem. Emmanuel Brett Porter a écrit : Hi, I've narrowed down the problem in upgrading from alpha-2 to beta-1 to the following model change: field namebuildDefinition/name version1.1.0+/version association xml.reference=true stash.part=true jpox.dependent=false typeBuildDefinition/type /association /field The problem here is that Continuum has no idea how to pre-populate the value for this. Should we/can we simply add a default value of null for this? Or will the data management app need some smarts to set it to the default build definition where it doesn't exist? Thanks, Brett -- jesse mcconnell [EMAIL PROTECTED]
Re: [OT] Mini-interview with Emmanuel Venisse
Emmanuel is French!?!?!?!?! :) On 8/6/07, Brett Porter [EMAIL PROTECTED] wrote: Hi all, I already posted this to the users@ list, but I thought some folk here might be more particularly interested in what Emmanuel had to say when we talked recently: http://www.devzuz.org/?q=node/12. Enjoy! Cheers, Brett -- jesse mcconnell [EMAIL PROTECTED]
maven.zones.apache.org back
http://maven.zones.apache.org/continuum/groupSummary.action continuum on maven.zones.apache.org is back up and running.. jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] release Maven parent POM v6
+1 On 8/9/07, Vincent Siveton [EMAIL PROTECTED] wrote: 2007/8/8, Dennis Lundberg [EMAIL PROTECTED]: Jakarta Commons has moved to TLP and I'd like to update the URLs for the Commons projects in the javadoc-plugin configuration. Same thing for velocity API. Vincent Other than that I'm +1. Brett Porter wrote: I'd like to release the parent to capture the changes that have been made for use in future releases. From r563503. Changes include: - clean up the developers list - update the remote-resources and gpg plugin versions used for releases - add default compiler and jar configuration settings +1 from me. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - 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] -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] Olivier Lamy as Continuum committer
+1 On 8/13/07, Lukas Theussl [EMAIL PROTECTED] wrote: +1 -Lukas Emmanuel Venisse wrote: Hi, I'd like to give to Olivier commit access to Continuum. He provided lot of good patches, implemented new features (installations/profiles) and help users on the mailing lists here, my +1 Emmanuel - 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] -- jesse mcconnell [EMAIL PROTECTED]
Re: The Maven PMC welcomes Deng Ching
Welcome Deng! :) On 8/21/07, Arnaud HERITIER [EMAIL PROTECTED] wrote: Welcome Deng ! cheers Arnaud On 21/08/07, Brian E. Fox [EMAIL PROTECTED] wrote: Welcome and congrats! -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Monday, August 20, 2007 7:20 PM To: Maven Developers List Subject: The Maven PMC welcomes Deng Ching I'm pleased to announce that the Maven PMC has voted to add Deng Ching to the PMC. Please join me in welcoming her! -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
updating continuum version on zones
fyi, I am pulling down the continuum instance on maven.zones.apache.org in order to update it to the latest beta version.. I'll ping when I get it back up, jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: updating continuum version on zones
and the maven zone is back up now.. cheerio! jesse On 8/29/07, Jesse McConnell [EMAIL PROTECTED] wrote: fyi, I am pulling down the continuum instance on maven.zones.apache.org in order to update it to the latest beta version.. I'll ping when I get it back up, jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] Release Continuum 1.1-beta-3
+1, nice job folks :) On 9/21/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: Damien Lecan 2 a écrit : Everyone is encouraged to vote and give their feedback. Page group summary is now very fast, database upgrade for Mysql works (almost), so Great, thx for your patch. We'll apply it. Emmanuel +1 (non binding) Damien Lecan -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] Nicolas de Loof as a committer
+1 On 11/21/07, Ralph Goers [EMAIL PROTECTED] wrote: +1 Ralph Brett Porter wrote: I'd like to call a vote for Nicolas de Loof as a committer, based primarily on his work for Archiva, but also from being active in the general Maven community for quite some time. He has been relentlessly testing and identifying issues and providing patches recently. +1 from me - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] Release Continuum 1.1 Final
+1
On 11/21/07, olivier lamy [EMAIL PROTECTED] wrote:
+1
--
Olivier
2007/11/19, Emmanuel Venisse [EMAIL PROTECTED]:
I fixed it.
About the doc, I'll work on it this week and it will be deploywhen the
vote will be ok.
Emmanuel
Emmanuel Venisse a écrit :
I'll fix it today and will resend a message when you'll can retest.
Emmanuel
Stuart James Penrose a écrit :
Emmanuel Venisse wrote:
The binaries are available there: ...
http://people.apache.org/builds/maven/continuum/1.1/org/apache/maven/continuum/data-management-cli/1.1/data-management-cli-1.1-app.jar
The data management tool looks like it needs some 'assembly' work
('java -jar data-management-cli-1.1-app.jar' doesn't work):
1) If you list the root of the jar you see a list of *.jar entries,
not root package names
2) It appears that the main class is missing (DataManagementCli)
- xmlrpc backup tool :
http://people.apache.org/builds/maven/continuum/1.1/org/apache/maven/continuum/continuum-xmlrpc-backup/1.1/continuum-xmlrpc-backup-1.1-app.jar
The file generated by the backup tool can be used with data
management cli to re-import data.
How does the xml backup tool relate to the cli tool the recommended
backup/restore/upgrade strategy in general? Should the upgrade page
make mention of this new tool
(
http://maven.apache.org/continuum/documentation/1_1/installation/upgrade.html
)?
Everyone is encouraged to vote and give their feedback.
[ ] +1 Release it!
[ ] 0
[ ] -1 Don't release it, because...
-1 Don't release it, because the data management tool is broken and
as
a result it's not clear how to upgrade 1.1-betaX installs to 1.1final.
Stu Penrose
--
jesse mcconnell
[EMAIL PROTECTED]
Re: [discuss] Graduate Continuum to its own TLP
+1 I still think this is a great idea... On Dec 22, 2007 6:34 AM, Emmanuel Venisse [EMAIL PROTECTED] wrote: I'm ok too, but I don't have the time to work on it. Emmanuel Olivier Lamy a écrit : Hi, Agree to start processing this. If I can help I will. -- Olivier 2007/12/20, Brett Porter [EMAIL PROTECTED]: So, what's next? This seems generally in favour - now might be a good time to get started on it? From past experience the steps would be: - poll the current maven committers to see who is interested in participating in the TLP - draft a resolution with those committers as the initial PMC - vote on sending the resolution to the board The board next meets in mid-January. Any thoughts on moving forward with this? - Brett On 24/09/2007, at 6:59 AM, Wendy Smoak wrote: On 9/21/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: 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. It definitely feels like it's time for this to happen, or at least to start the process. Assuming there is general agreement here, let's talk about it on [EMAIL PROTECTED] and see who else might be interested in joining us in a TLP. IMO, anyone who has access to the code now as part of Maven is welcome to come along when it moves out, or at any point in the future. That's how we handled the Tiles move (from Struts) and it worked well. -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: Dramatically speed up dependency resolution
and I don't think 2.1 has any kind of firm release date planned jesse On Jan 27, 2008 5:29 PM, Don Brown [EMAIL PROTECTED] wrote: Using Java 1.4 will require using the backport of the concurrent utils, which according to Jason, had some difficulty working with the 2.0 stable branch. Also, considering the incompatibility of commons-logging with some plugins, the http wagon should probably only go into the 2.1 branch. So, if you are using Java 5, feel free to use my uber jar or apply the patches yourself. If you want an official maven release, looks like 2.1 will be the earliest it'll see the light of day. Don On 1/28/08, Brian E. Fox [EMAIL PROTECTED] wrote: Is it absolutely required to use 1.5? If there's a good way to work around it, we should aim for 2.0.9 -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Sunday, January 27, 2008 4:49 PM To: Maven Developers List Subject: Re: Dramatically speed up dependency resolution On 1/28/08, Jason van Zyl [EMAIL PROTECTED] wrote: * Connection pooling: Uses the http wagon instead of http-lightweight and fixed incorrect http client initialization James Dumay also worked on this. So you might want to talk to him or look. I'm not sure if you're the Don Brown from Atlassian. Ok WAGON-86. Yep, that fixes the connection pooling and adds timeouts to boot. This patch should really be applied ASAP as it will make a big different to users once the http wagon has been made the default. And yes, [EMAIL PROTECTED] == Don Brown from Atlassian * Parallel resolution of artifacts - Uses a thread worker pool to parallelize artifact resolution You should also be aware of the rewrite that Oleg Gusakov started and has a first working version for in maven-artifact trunk which will result in a dramatic simplification and optimization of the artifact resolution process. I'll push him to get the visualization tool he created out to the community so people can see it in action. Looking at the new code, I don't see any reason why the patch wouldn't work for the new version. The new version still processes each artifact serially when parallel would produce better results. If you sync up with James, the connection pooling we can get into Wagon. The artifact code please make sure you're working from maven- artifact trunk as we'll make an attempt shortly to integrate that. My only problem with porting it is I want to be using this code now. How stable is trunk? Is a 2.1 release around the corner? Don http://people.apache.org/~mrdon/maven-2.0.9-SNAPSHOT-uber.jarhttp://people.apache.org/%7Emrdon/maven-2.0.9-SNAPSHOT-uber.jar Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - 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] -- jesse mcconnell [EMAIL PROTECTED]
Re: Please comment: 2.1 Lifecycle Features on MAVEN Confluence space
Do you think this will also include the build context mechanics we talked about a long time ago? Where mojo's can communicate to each other a map of either status or configuration settings through some third party mechanism, perhaps the build plan this talks about. I seem to remember you putting some of that into trunk already but I could be wrong...anyway, that build context material would definitely have impact on this deterministic lifecycle your talking about. jesse On Jan 29, 2008 3:59 PM, John Casey [EMAIL PROTECTED] wrote: Right...I guess it'd help to include the URL: http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning Thanks! -john On Jan 29, 2008, at 4:58 PM, John Casey wrote: Hi all, I've written up the new features present in the refactored lifecycle support for 2.1, if anyone is interested in reading it. I'd like to hear what you all think, particularly about the emerging discussion of aggregator plugins, pre-exec plugins, and such taking place on the page comments. In brief, we have numerous problems with aggregator plugins, whether you're talking about binding these to a lifecycle phase, resolving dependencies of these plugins that actually are present in the current reactor, timing of execution (particularly in multimodule builds where the plugin needs the output of module builds, see the assembly plugin outstanding bugs for this one), and more. In addition, there has been an expressed need for a sort of pre-execution phase that would allow plugins to manipulate dependency lists, mojo bindings, etc. before the build proper starts. Finally, there is some discussion about mojos that can conditionally choose to fork a nested execution or not, depending on how they're used...which also brings up the idea of letting a mojo discover where and how it's being used. IMO, these issues represent the next iteration of Maven build definition. They are the next frontier for the work we're trying to do in Maven in many ways, and it seems like they deserve a healthy design discussion each. In the case of aggregator plugins and the pre-execution phase, it may make more sense to go back to first principles and see whether we can come up with a single replacement solution to aggregators that would address both types of problem. Please comment if you have an opinion on this. Thanks, -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john -- jesse mcconnell [EMAIL PROTECTED]
Re: Document Template
it is certainly a good place to start :) without looking through those continuum issues, I would say that your best bet is to dig into the code a bit, come up with a gameplan on what you think ought to be modified where, maybe a patch or three to th dev list and give us an idea what your thinking... cheers! and welcome :) jesse On Jan 30, 2008 8:25 AM, Richard Slide [EMAIL PROTECTED] wrote: Hello Everyone, I'd like to contribute to continuum community and I'll like to start work on: CONTINUUM-1344 CONTINUUM-1593 CONTINUUM-1549 In continuum road map 2.0 i read that it's necessary to have template, If yes could please tell me where I can find it. Is this the 'right' way to start to contribute ? Cheers --Richard -- jesse mcconnell [EMAIL PROTECTED]
Re: [Discussion] Continuum 2.0 Roadmap
How important is the database really to things in continuum? To me it has always seemed somewhat of an annoyance to have to manage and maintain when so much of things could just be some xml files on disk. There isn't a great amount of search functionality in continuum that in my mind begs a solution where someone could increase performance by tuning some sql statements. The largest chunks of historical data we maintain are things like build results and they could discovered and indexed in memory pretty easily I could think... but if we are going to stick with the database then I think the api needs to definitely take into account a more distributed nature where multiple continuum instance would feed into a single database...make it so that we can generate interesting information across mutliple distributed continuum instances out of that central database. I would also like to suggest that we either make use of a jdo impl that provides for lazy loaded objects where interacting with something like Project and calling a method on it will automatically populate what you need in your code, or else we implement it in a wrapper on these object so that the API into the store can be cleaner then this getProjectsWithEverythingUnderTheSunPopulated() vs getProjectThatYouAreEnsuredToNotHaveDataYouWantPopulated() methods. my 2 cents...maybe jpa would help clean this up but I know rahul and emm were talking about that not too long ago query wise...I think it would be most excellent to have one method to getProject() out of the store and have it be useful everywhere and all of the fleshing out of its content managed behind the scenes. jesse On Jan 30, 2008 10:27 AM, Gordon Yorke [EMAIL PROTECTED] wrote: TopLink has a large community of users and active forums at both Oracle and Glassfish. If you are concerned about licensing, Oracle has donated the full TopLink source to the Eclipse Foundation under the Eclipse Persistence Services (EclipseLink) project. If you have any questions the EclipseLink dev mailing list is well monitored. --Gordon Yorke Rahul Thakur wrote: 2) Database I am not hard and fast on any particular JPA provider. If Toplink cuts it, we should go with it. I have been toying around with OpenJPA, but I haven't used Toplink to comment on how both compare. OpenJPA is comprehensively documented and has a good support available on mailing lists. Having said that, JPA providers would ultimately be swap'able under the hood. Also, I think we should stick with JPA annotations on model entities instead of using Modello. I hope writing the data access code from scratch implies the current ContinuumStore will be refactored into something which is less verbose than what we have currently, and so would the Continuum interface. -- View this message in context: http://www.nabble.com/-Discussion--Continuum-2.0-Roadmap-tp15171171p15184536.html Sent from the Continuum - Dev mailing list archive at Nabble.com. -- jesse mcconnell [EMAIL PROTECTED]
Re: Please comment: 2.1 Lifecycle Features on MAVEN Confluence space
well, when your working with something that will try and predetermine how and when plugins will run and you have something like build context/state in play then plugins will be able to turn themselves off depending on build state based on the context of the build up to that point...which kinda interfers with the overall build plan...at least in deterministically knowing what would happen first jesse On Jan 30, 2008 1:45 PM, John Casey [EMAIL PROTECTED] wrote: How do you see that impacting the lifecycle stuff, out of curiosity? I did put the build context into trunk, but wound up taking it back out because it wasn't implemented very well, and was leading to a proliferation of separate, threadlocal-driven storage classes. I've been thinking for awhile now that it doesn't matter how much we revamp the actual apis, we're going to be left with a need to access the current build-state from components that have no direct access to the parts of Maven they need, because of an api bottleneck like passing through the ArtifactMetadataSource interface to bridge together MavenMetadataSource and MavenProjectBuilder. I've been thinking about this more in terms of a plexus component that contains the build state and uses a per-thread instantiation strategy (doesn't exist yet)...but I don't have anything concrete yet. -j On Jan 30, 2008, at 2:17 PM, Jesse McConnell wrote: Do you think this will also include the build context mechanics we talked about a long time ago? Where mojo's can communicate to each other a map of either status or configuration settings through some third party mechanism, perhaps the build plan this talks about. I seem to remember you putting some of that into trunk already but I could be wrong...anyway, that build context material would definitely have impact on this deterministic lifecycle your talking about. jesse On Jan 29, 2008 3:59 PM, John Casey [EMAIL PROTECTED] wrote: Right...I guess it'd help to include the URL: http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle +Planning Thanks! -john On Jan 29, 2008, at 4:58 PM, John Casey wrote: Hi all, I've written up the new features present in the refactored lifecycle support for 2.1, if anyone is interested in reading it. I'd like to hear what you all think, particularly about the emerging discussion of aggregator plugins, pre-exec plugins, and such taking place on the page comments. In brief, we have numerous problems with aggregator plugins, whether you're talking about binding these to a lifecycle phase, resolving dependencies of these plugins that actually are present in the current reactor, timing of execution (particularly in multimodule builds where the plugin needs the output of module builds, see the assembly plugin outstanding bugs for this one), and more. In addition, there has been an expressed need for a sort of pre-execution phase that would allow plugins to manipulate dependency lists, mojo bindings, etc. before the build proper starts. Finally, there is some discussion about mojos that can conditionally choose to fork a nested execution or not, depending on how they're used...which also brings up the idea of letting a mojo discover where and how it's being used. IMO, these issues represent the next iteration of Maven build definition. They are the next frontier for the work we're trying to do in Maven in many ways, and it seems like they deserve a healthy design discussion each. In the case of aggregator plugins and the pre-execution phase, it may make more sense to go back to first principles and see whether we can come up with a single replacement solution to aggregators that would address both types of problem. Please comment if you have an opinion on this. Thanks, -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john -- jesse mcconnell [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john -- jesse mcconnell [EMAIL PROTECTED]
Re: Please comment: 2.1 Lifecycle Features on MAVEN Confluence space
yes, I see what your talking about.. And I think your might be onto something with your BuildPlanModifier bit...It seems to me that plugins have perhaps grown a bit too...powerful in terms of how they can effect the build. I wonder if it might be a good time while your looking into all of this to take a look at the totality of plugins out there and maybe slice this problem up a bit. There are a ton of plugins that have a really clear separation of concerns in term of the overall build. But it gets murky really quick. Source generation plugins for example, they do one thing and one thing well, they generate a mess of source and then tell maven that it needs to consider these things when building from that point on...basically configuring something like that compiler plugin on the fly during plugin execution...or sometimes skipping execution if they already have run. It might be prohibitively a pain in the arse to do, but perhaps it would nice to flesh out some additional specific Mojo++ interfaces that your build. Source generation plugins all share many facets... * they generate source someplace * they conditionally run or not based on source * they influence another phase of the lifecycle specifically (like the compiling and test compiling) I could easily see another case where X different mojo's can be used to fork off running process in one phase and be shut down in another (testing webservices in your build by deploying into a container, running selenium against it and then shutting container down). The normal Mojo interface is very simple and lets you do a massive amount of different things...would it make sense to expand on that a bit while your at it with this build planning working? it might net you some more information and make the build planning more informative and declarative. jesse On Jan 31, 2008 9:52 AM, John Casey [EMAIL PROTECTED] wrote: You know, I've been thinking about that bit, too...turning mojos off, replacing them, etc, I mean. What I'm currently thinking is that a build extension that carried its own configuration might be a good alternative, though I'm not sure how well that would scale. The idea is to introduce a hook for modifying the build plan before the lifecycle executor, session, or execution-result can get their hands on it. The modifier hook would basically be a lookup for all extensions that implement BuildPlanModifier in the current project's lookup realm, then just iterating through them...the result would be passed back to Maven for execution, reference, etc. I think we're starting to stretch the constraints on what a normal plugin (i.e. something that functions during the building of a project) is supposed to do. The idea of a build-plan modifier is almost a meta-plugin, in that it modifies the system of plugins that execute the build, and it dovetails pretty neatly with some other similar hooks I could imagine that are related to Brian's first and third comments on the Deterministic Lifecycle Planning page, citing the need to have pre-execution and post-execution phases, where things can modify dependencies, cleanup after a build (think finally clause, at least that's what it reminds me of), etc. This is really bigger than your normal plugin, in that it modifies the system itself, not the target project. However, to do this, we would really need to talk about providing a configuration section in the build extensions section of the POM, to allow the ordering and options given to these modifiers to be stated plainly alongside the normal plugin configuration (getting back to that determinism goal). Does this all make sense? -john On Jan 30, 2008, at 2:58 PM, Jesse McConnell wrote: well, when your working with something that will try and predetermine how and when plugins will run and you have something like build context/ state in play then plugins will be able to turn themselves off depending on build state based on the context of the build up to that point...which kinda interfers with the overall build plan...at least in deterministically knowing what would happen first jesse On Jan 30, 2008 1:45 PM, John Casey [EMAIL PROTECTED] wrote: How do you see that impacting the lifecycle stuff, out of curiosity? I did put the build context into trunk, but wound up taking it back out because it wasn't implemented very well, and was leading to a proliferation of separate, threadlocal-driven storage classes. I've been thinking for awhile now that it doesn't matter how much we revamp the actual apis, we're going to be left with a need to access the current build-state from components that have no direct access to the parts of Maven they need, because of an api bottleneck like passing through the ArtifactMetadataSource interface to bridge together MavenMetadataSource and MavenProjectBuilder. I've been thinking about this more in terms of a plexus component that contains
Re: [vote] Request Graduation to a TLP
+1 On Feb 5, 2008 5:06 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged. -- jesse mcconnell [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
+1 in principle. One thought thoughwhat if we were to add the activeProfile element as it exists in the settings.xml into the pom.xml and advertise that users can set something like this in their top level pom.xml: profiles activeProfiles activeProfiledefault-maven-plugin-versioning/activeProfile /activeProfiles /profiles This lets the behavior be optional, to be enabled as desired, is additive to the pom.xml and accomplishes all of the same goals. We advertise the hell out of it and people will discover it as they have a problem that they resolve, can migrate to it as an upgrade process in their company environments and we don't screw someone over with our benevolent power. thoughts? jesse On Feb 9, 2008 7:59 AM, Benjamin Bentmann [EMAIL PROTECTED] wrote: simply discuss the ramifications of defaulting the core plugin versions in the super pom in 2.0 only. +1, might also spare users from learning yet another concept like plugin-packs. If the super POM locks down all plugins that would be injected by one of the various lifecycle mappings and the user himself locks down any additional plugins he explicitly configured in the POM, why bother with something like plugin-packs. Besides, I do not see much value in an attempt to pack/group plugins given the fact that each plugin has its own release cycle, i.e. there are more version combinations of plugins from which I want to choose than you want to provide plugin packs for. Last but least and please don't take this as an offense but if you are honest you have to confess that implementation of inheritance is buggy/complex enough. As a user interested in a stable build tool, I really dislike the idea of another concept that interferes with plugin resolution. Those who have followed best practice and locked their versions down will not be affected by this at all. The reality looks different: http://jira.codehaus.org/browse/MNG-3394 As a prerequisite for the proposed additions to the super POM, this issue should be fixed. Regards, Benjamin Bentmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Maven and preset plugin versions
is for children pom to provide the better versions if necessary, but Maven should at least provide the minimum versions. Paul -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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] - 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] -- jesse mcconnell [EMAIL PROTECTED]
Re: Continuum Security design
There was some discussion on irc about the security model so I wrote up this description for review by everyone. http://docs.codehaus.org/display/CONTINUUM/Straight+Role+Based+Access+Control It doesn't have implementation details in it, it is just an attempt at drawing together the different concepts we have been talking about together so we can agree on 'what we want' and then we can focus on 'how to do it'. personally, I think this basic idea could go into plexus (if it isn't already there with jason's rbac stuff) pretty smoothly and then have different implementations like carlo's acegi stuff... but anyway, please review the above and comment cheers! jesse On 7/18/06, Brett Porter [EMAIL PROTECTED] wrote: I've added my comments. I don't think we need domain ACLs - it's an interesting concept but it also worries me a little to have security as an afterthought - it's intrinsic to the design of the code in some ways (surely if you only want to give one person access to a subset of the data you also want to avoid going ahead and retrieving the data in the first place). Perhaps I misunderstand it's intent. So, where are we at with this? I don't think its healthy to keep a branch for too long on something so fundamental as it'll become hard to merge back in, but is Acegi proving to be both non-intrusive and capable of doing what we need? What state is it in? - Brett On 11/07/2006 8:41 AM, Carlos Sanchez wrote: http://docs.codehaus.org/display/CONTINUUM/Security Please take a look and provide feedback on the semantics of what to secure and to what level. -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ -- jesse mcconnell [EMAIL PROTECTED]
Re: Continuum Security design
I have been working on a little security api in the plexus sandbox that I wanted to describe to the continuum dev list that would work for the implementation of the authentication and authorization parts of continuum. I like it since it is pretty easy to use and should extend to support the zones ideas we have been describing in some of these discussions on irc and on this mailing list. Basically its an object called a PlexusSecurityRealm that is configured in the components.xml to have an AuthenticationStore and an AuthorizationStore. These stores have one method each called authenticate( tokenMap ) and authorize( session, tokenMap ). The PSR has some convience methods for working with these so you can call things like isAuthentic( tokens ) or isAuthorized( session, tokens ). I made a simple implementation of both stores and then an acegi authentication store as well so far. The acegi authentication store is nice in that it is also all configured in the components.xml file and can link up to whatever acegi can for authentication purposes. Now the authorization side of the fence is a little more murky. I am really trying to seperate out the authentication process, authorization process and the gathering if user details and stuff. Acegi implementation really binds the authentication and authorization concepts together which makes it difficult to wrap them up as distinct seperate components. I have an Object in that AuthenticationResult object that is returned from the authentication store where we can shove the acegi authentication object and the authorization store can make use of that. I think the real big decision that needs to be made in regards to continuum and authentication/authorization is how implementation specific do we want to go? Acegi has a whole host of fun little bells and whistles but they are peppered all through your code or are injected in the flow of things through web filters and the like. This lets you do fun little things like secure all the user management code behind a particular url, say **/users/*, with a particular role or something. It provides some taglibs for optionally rendering page content based on roles. It also has a pretty strong aop integration that lets you manage security of objects in your codebase without actually modifying any of your code. My thinking on the matter was more along the lines of letting whatever object in the system, be it webwork rendering, data objects, or flow control to be able to have one object that they could ask isAuthentic( X ) and/or isAuthorized( X ) and react accordingly and let all the howto mumbo jumbo be configured in other components. Plexus would basically manage all the nuts and bolts of what to authenticate to and authorize on and the application code would just ask the questions itself. This has the benefit of readability but probably isn't as nimble an idea as the aop bits of acegi. does anyone have any feelings one way or the other on this? jesse On 7/19/06, Jesse McConnell [EMAIL PROTECTED] wrote: There was some discussion on irc about the security model so I wrote up this description for review by everyone. http://docs.codehaus.org/display/CONTINUUM/Straight+Role+Based+Access+Control It doesn't have implementation details in it, it is just an attempt at drawing together the different concepts we have been talking about together so we can agree on 'what we want' and then we can focus on 'how to do it'. personally, I think this basic idea could go into plexus (if it isn't already there with jason's rbac stuff) pretty smoothly and then have different implementations like carlo's acegi stuff... but anyway, please review the above and comment cheers! jesse On 7/18/06, Brett Porter [EMAIL PROTECTED] wrote: I've added my comments. I don't think we need domain ACLs - it's an interesting concept but it also worries me a little to have security as an afterthought - it's intrinsic to the design of the code in some ways (surely if you only want to give one person access to a subset of the data you also want to avoid going ahead and retrieving the data in the first place). Perhaps I misunderstand it's intent. So, where are we at with this? I don't think its healthy to keep a branch for too long on something so fundamental as it'll become hard to merge back in, but is Acegi proving to be both non-intrusive and capable of doing what we need? What state is it in? - Brett On 11/07/2006 8:41 AM, Carlos Sanchez wrote: http://docs.codehaus.org/display/CONTINUUM/Security Please take a look and provide feedback on the semantics of what to secure and to what level. -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Continuum Security design
carlos, how would you recommend we implement the users/groups/roles/permissions material that we have already been discussing? would it be implementing the rbac model using the AccessDecisionManager and AccessDecisionVoter dealio in acegi? I can see how we might go about doing it in acegi, it would be a matter of figuring out how to map the rbac data into GrantingAuthorities that would be setup during the authentication, and then figuring out how that pans out in the authorization side of things... what are your thoughts on getting the rbac aspect of authorization working with acegi? jesse On 7/26/06, Carlos Sanchez [EMAIL PROTECTED] wrote: I think is more important now come with a good representation of users, groups, roles,... that can be used across all apps (Continuum, MRM,...) Acegi doesn't mess with your code, so the need of another api on top of it for me has no much sense. I like the aop approach better than implementing interfaces for the same reason, it doesn't get in your way. You can secure anything pretty easily. I have made some progress on this but other things needed my attention, I'll have the integration bits ready soon. On 7/26/06, Jesse McConnell [EMAIL PROTECTED] wrote: I have been working on a little security api in the plexus sandbox that I wanted to describe to the continuum dev list that would work for the implementation of the authentication and authorization parts of continuum. I like it since it is pretty easy to use and should extend to support the zones ideas we have been describing in some of these discussions on irc and on this mailing list. Basically its an object called a PlexusSecurityRealm that is configured in the components.xml to have an AuthenticationStore and an AuthorizationStore. These stores have one method each called authenticate( tokenMap ) and authorize( session, tokenMap ). The PSR has some convience methods for working with these so you can call things like isAuthentic( tokens ) or isAuthorized( session, tokens ). I made a simple implementation of both stores and then an acegi authentication store as well so far. The acegi authentication store is nice in that it is also all configured in the components.xml file and can link up to whatever acegi can for authentication purposes. Now the authorization side of the fence is a little more murky. I am really trying to seperate out the authentication process, authorization process and the gathering if user details and stuff. Acegi implementation really binds the authentication and authorization concepts together which makes it difficult to wrap them up as distinct seperate components. I have an Object in that AuthenticationResult object that is returned from the authentication store where we can shove the acegi authentication object and the authorization store can make use of that. I think the real big decision that needs to be made in regards to continuum and authentication/authorization is how implementation specific do we want to go? Acegi has a whole host of fun little bells and whistles but they are peppered all through your code or are injected in the flow of things through web filters and the like. This lets you do fun little things like secure all the user management code behind a particular url, say **/users/*, with a particular role or something. It provides some taglibs for optionally rendering page content based on roles. It also has a pretty strong aop integration that lets you manage security of objects in your codebase without actually modifying any of your code. My thinking on the matter was more along the lines of letting whatever object in the system, be it webwork rendering, data objects, or flow control to be able to have one object that they could ask isAuthentic( X ) and/or isAuthorized( X ) and react accordingly and let all the howto mumbo jumbo be configured in other components. Plexus would basically manage all the nuts and bolts of what to authenticate to and authorize on and the application code would just ask the questions itself. This has the benefit of readability but probably isn't as nimble an idea as the aop bits of acegi. does anyone have any feelings one way or the other on this? jesse On 7/19/06, Jesse McConnell [EMAIL PROTECTED] wrote: There was some discussion on irc about the security model so I wrote up this description for review by everyone. http://docs.codehaus.org/display/CONTINUUM/Straight+Role+Based+Access+Control It doesn't have implementation details in it, it is just an attempt at drawing together the different concepts we have been talking about together so we can agree on 'what we want' and then we can focus on 'how to do it'. personally, I think this basic idea could go into plexus (if it isn't already there with jason's rbac stuff) pretty smoothly and then have different implementations like carlo's acegi stuff... but anyway, please review the above
Re: using standard maven site template
+1, that can only be a good thing On 8/2/06, Brett Porter [EMAIL PROTECTED] wrote: Hi, I've created a skin (maven-application-skin), which is the maven-theme.css and images needed to do the Continuum lf with the normal Maven page layout (ie, css layout, not tables like in Continuum right now). Thought this might be worth updating in the Continuum decorator (the decorator from MRM can be used replacing the navigation items and header footer - though the other html tags can be used). I've tested it in IE6/7 and Firefox 2. This would mean we can have consistent guidelines for skinning sites and Continuum/MRM. WDYT? Cheers, Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ -- jesse mcconnell [EMAIL PROTECTED]
continuum project groups
on the security thread there was some dicussion of project grouping, which is also on the continuum roadmap for 1.1 and in jira under a number of issues, CONTIUUM-30 being one of the original ones.. I have been taking a stab at this locally and wanted to see if I could get some feedback for this before I start submitting patchs for it. My general idea is partially on the white-site that brett commited last week but this is the general idea. The front page for continuum right now is the summary.jsp page which lists out all of the projects in continuum. These are internally structured into project groups which only appear on that summary page as a column giving the name of the project group. What I have done so far is create a groupSummary.jsp and associated view model and action that allows the front page to render out each project group and the projects inside of it, the projects render with a bit less of the information then the straight summary page, but the title for each table of projects is clickable taking you to the old summary.jsp page which has been pared down to contain just the projects in a particular project group. So basically you have the front page able to render out all projects broken out into seperate tables based on project group. my intention now is to make project group configuration pages that let you initially setup notifiers and whatnot at the top lvl that would be replicated through all of the child projects, this should make project group management easier as right now you have to go through each project one by one to configure those things. The singular project management would remain the same, only it would allow you to tweak the items setup by the top lvl project group management screens. I'll try and go through and align the white-site with this as well but I also want to get it themed right with the current look and feel (and bretts new new look and feel he commented about on another thread) oh, and once this kinda functionality is in place then it should be pretty easy to make a project group lvl setting for things like 'build on dependency changes' thoughts? jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: continuum project groups
question for anyone listening regarding project grouping and things like notifiers and build definitions. I am working through making a project group utility class for hiding some of this kinda logic from the webapp actions and ran across a little issue in terms of the model. Using build definitions as an example, each build definition uses an integer id that is the only test for equality in a .equals(object) test. Now when I am running through all of the projects in a project group I would like to aggregate these guys together based on equality in all fields other then the id because at the project group lvl they should present as equal if their arguments and schedules are identical. Conversely when I am applying a build definition back to each of the projects I would like to maintain that same build definition across different projects. This basically results in a slightly different model being returned after aggregating and modifying equivalent build definitions. 1) does anyone see this as a problem in handling it this way? I could proxy the equivalent build defintions somehow and maintain their original build id's but that just seems silly to me given my current understanding 2) would I be better off adding the ability to set build definitions and notifiers to the ProjectGroup in the model and dealing with things that way? I think it is important to maintain this kinda individual notifiers and build defintions on the project level for one off hacks and special needs, but I see the natural evolution of project groups in continuum making it much easier to influence those kinda things (build definitions and notifiers) at the project lvl and having them inherited by project members... thoughts? answers? slap downs? :) jesse On 8/3/06, Jesse McConnell [EMAIL PROTECTED] wrote: on the security thread there was some dicussion of project grouping, which is also on the continuum roadmap for 1.1 and in jira under a number of issues, CONTIUUM-30 being one of the original ones.. I have been taking a stab at this locally and wanted to see if I could get some feedback for this before I start submitting patchs for it. My general idea is partially on the white-site that brett commited last week but this is the general idea. The front page for continuum right now is the summary.jsp page which lists out all of the projects in continuum. These are internally structured into project groups which only appear on that summary page as a column giving the name of the project group. What I have done so far is create a groupSummary.jsp and associated view model and action that allows the front page to render out each project group and the projects inside of it, the projects render with a bit less of the information then the straight summary page, but the title for each table of projects is clickable taking you to the old summary.jsp page which has been pared down to contain just the projects in a particular project group. So basically you have the front page able to render out all projects broken out into seperate tables based on project group. my intention now is to make project group configuration pages that let you initially setup notifiers and whatnot at the top lvl that would be replicated through all of the child projects, this should make project group management easier as right now you have to go through each project one by one to configure those things. The singular project management would remain the same, only it would allow you to tweak the items setup by the top lvl project group management screens. I'll try and go through and align the white-site with this as well but I also want to get it themed right with the current look and feel (and bretts new new look and feel he commented about on another thread) oh, and once this kinda functionality is in place then it should be pretty easy to make a project group lvl setting for things like 'build on dependency changes' thoughts? jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: continuum project groups
john casey and I talked on irc a bit and we were leaning towards the idea of adding ProjectGroup lvl BuildDefinitions as a good way to go. then on the ProjectGroup display we can easily display the inherited build definitions and on the individual project pages we can render out two tables, one for inherited build defintions and then the project specific ones should they exist. Or in the existing buildDefinitions table with a column for inherited and local definitions. This solves the issue of aggregating the project group lvl build definitions up to a single statement and then pushing them back down into the projects with unique build definition ids. anyway, that was our thought, others are welcome, I am going to dig into the model a bit and see about adding this and maybe a utility method on the ProjectGroup object in the model for aggregating them based on the known projects in the project group. jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: continuum project groups
I suppose I should have looked at the model in the first place. the model appears to support the build definitions and project notifiers at the project group lvl already, I just don't see support for that in the continuum-api or in the continuum-store atm...so looks like that is probably the right place to be heading on this.. has anyone worked on this before by chance? jesse On 8/7/06, Jesse McConnell [EMAIL PROTECTED] wrote: john casey and I talked on irc a bit and we were leaning towards the idea of adding ProjectGroup lvl BuildDefinitions as a good way to go. then on the ProjectGroup display we can easily display the inherited build definitions and on the individual project pages we can render out two tables, one for inherited build defintions and then the project specific ones should they exist. Or in the existing buildDefinitions table with a column for inherited and local definitions. This solves the issue of aggregating the project group lvl build definitions up to a single statement and then pushing them back down into the projects with unique build definition ids. anyway, that was our thought, others are welcome, I am going to dig into the model a bit and see about adding this and maybe a utility method on the ProjectGroup object in the model for aggregating them based on the known projects in the project group. jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: svn commit: r430182 - /maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/ContinuumActionSupport.java
grr, idea template error On 8/9/06, Brett Porter [EMAIL PROTECTED] wrote: On 10/08/2006 9:11 AM, [EMAIL PROTECTED] wrote: + * Copyright 2005 The Codehaus. Cut and paste error? - Brett -- jesse mcconnell [EMAIL PROTECTED]
Re: svn commit: r430090 - /maven/continuum/trunk/continuum-webapp/pom.xml
I know I caught the reason from you guys on IRC this morning, apparently
plexus.xml wasn't working - but I'd like to get to the bottom of it.
correct, the specific error when using the plexus.xml was that when
the actions where being loaded we were getting ClassNotFoundExceptions
on the action classes themselves, so the xwork - plexus.xml mapping
was working, but when the o.a.m.c.w.a classes (not their webwork
hints) were being loaded it couldn't find them (and the are in the
same artifact as the plexus.xml!)
Are you sure this entirely works? What about if you have
non-components.xml descriptor elements like load-on-start?
so far everything I have been doing with the UI has been working fine
one possible difference I have noticed is that the jdo store is not
loading up until it is first accessed, which is a different behavior
then before, which make senses if its load-on-start...
I may have made a mistake when applying it to continuum, but plexus.xml
is definitely working in MRM, and that is what the xwork integration
attempts to use to configure everything so I'm not sure this is going to
do everything you need.
I am not sure what to say here, you can easily replicate our situation
by changing that pom back to the plexus.xml and simply try and start
up continuum with the jetty webapp, the CNFE stack traces pour out.
jesse
On 10/08/2006 2:36 AM, [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Wed Aug 9 09:36:28 2006
New Revision: 430090
URL: http://svn.apache.org/viewvc?rev=430090view=rev
Log:
The merged component descriptor must be in components.xml instead of
plexus.xml
Modified:
maven/continuum/trunk/continuum-webapp/pom.xml
Modified: maven/continuum/trunk/continuum-webapp/pom.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/pom.xml?rev=430090r1=430089r2=430090view=diff
==
--- maven/continuum/trunk/continuum-webapp/pom.xml (original)
+++ maven/continuum/trunk/continuum-webapp/pom.xml Wed Aug 9 09:36:28 2006
@@ -53,7 +53,7 @@
execution
idmerge/id
configuration
-
output${project.build.outputDirectory}/META-INF/plexus/plexus.xml/output
+
output${project.build.outputDirectory}/META-INF/plexus/components.xml/output
descriptors
descriptor${project.build.directory}/generated-resources/plexus/plexus.xml/descriptor
descriptorsrc/main/plexus/plexus.xml/descriptor
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
--
jesse mcconnell
[EMAIL PROTECTED]
Re: Progress update Re: [VOTE] Rename repository manager
+1 archiva archivist ought to the a user role in the app :) On 8/14/06, Edwin Punzalan [EMAIL PROTECTED] wrote: I'm changing my vote to Archiva, too... thanks to Martin. ^_^ Brett Porter wrote: We currently have: Curator: 13 Librarian: 2 Archiva: 7 (this is assuming Martin and Joakim voted for Archiva) While I said 72 hours, that fell over the weekend so I'll look at this again in 12 hours. I'm starting to lean towards Archiva or a new one: Archivist (according to Wikipedia, An archivist is a professional who assesses, collects, organizes, preserves, maintains control over, and provides access to information determined to have permanent value.) On 10/08/2006 9:57 AM, Brett Porter wrote: Please vote for one of the following names: [ ] Archiva [ ] Curator [ ] Librarian [ ] Nexus [ ] Repository Manager (ie, don't change it) I'm going to add the following votes for curator from the previous thread so no need to vote again unless you'd like to change it (none of the others expressed a preference for a single one other than proposing it): Brian Fox, Allan Ramirez, Maria Odea Ching, Edwin Punzalan, Brett Porter, Wendell Beckwith We will create mailing lists: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Then, SVN will be renamed and I'll put together a beta release. Vote will close in 72 hours. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPOX errors on startup
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 -- jesse mcconnell [EMAIL PROTECTED]
continuum alpha releases
Kenney and I were talking today about breaking up continuum 1.1 release in jira into a couple of smaller more managable chunks, like perhaps a couple of alpha releases. I was thinking that we could probably target an alpha-1 release of continuum 1.1 for the end of the month. There is the complete webwork UI revamp, my project grouping changes, and a number of little fixes here an there. Kenney and I were thinking that between the two of us we could pretty easily wrap up some outliers for an alpha-1 release in pretty short order.. even if we didn't release it from the website, we could just tag it and move on, letting us organize continuum jira a bit clearer. anyone have thoughts on that? jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: plexus security components
Well RBAC pretty much takes care of this, being a general authorization system. Let me see if I can do it justice here.. A user is pretty easy, its the biological or computational machine that is using the system. A role can be assigned to a user, multiple users can be assigned to a role, and a role can be the parent to one or more roles. Those child roles gain all the permissions their parent have, the hierarchical groups you were mentioning above. An operation is something that can be performed on an object, reading a file object, writing a file object, deploying an artifact to a repository, etc. A permission is assigned to a role and is what is required to authorize the operation on some object. So, an example of this working in archiva would be similar to: * Brett is an authenticated user of archiva. * Brett is assigned the role of Project Maintainer for the 'org.apache.maven' project * Operations for project objects may include things like 'deploying, removing, updating'. * The Object that brett will be performing operations on is 'org.apache.maven' * The Project Maintainer role for 'org.apache.maven' has permission to perform the deploy and update operations. Brett decided he wants to deploy a new snapshot for the 'org.apache.maven' project so when authorization is checked for this activity the check for permission is made for the DEPLOY operation on the 'org.apache.maven' OBJECT. The Project Maintainer role gives the P(DEPLOY, 'org.apache.maven') permission so this activity is authorized. Now multiple permissions might be required to actually complete this activity, I could easily see that the Project Maintainer role might need to exist for each repository being managed, and permissions would be allocated such that that role has the ability to deploy something to the repository in question. These would be other permission checks that would be made to authorize the particular behavior. RBAC has a concept for this as well called constraints, a constraint for the deploy operation above might be that the user has permission to deploy to the repository in question. This is why we think rbac is a good solution for this, with a bit of intelligence we can layout a role hierarchy that will make maintaince a breeze, just click through some UI and grant the roles for particular 'org.apache.maven' type projects to the relevant people. Now this is an example of how it could work, its by no means the hard and fast way it will be/should be implemented. jesse
Re: send patches where?
probably a good idea to pop onto irc as well, we do a fair amount of collaboration on there and its useful to ping folks to make sure that effort isn't getting duplicated irc.codehaus.org #continuum cheers! jesse On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 12:04 AM 30 Aug 06, Brill Pappin wrote: I decided to take some time and tackle some of the very large number of issues in Jira... however I don't have svn commit access. Is there any particular place I should send patches... and what format should the patches be in? Are you an Apache committer? We are setting up a sandbox where Apache committers can collaborate. - Brill Pappin Jason van Zyl [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: I´m lost in the architecture
the trunk isn't working with the plexus-application atm.. your best bet to test something like this is to build everything from the top level and go into the continuum-webapp directory and run something like mvn jetty:run that will start continuum up on localhost port 9090 and you can test things out accordingly cheers! jesse On 8/30/06, Lucas Gonçalves [EMAIL PROTECTED] wrote: First of all, sorry about my English! I need some features. In a resultbuild page of the projects a need know the revision(svn) from the build was done. Second i need to put the link of project´s site in main page, the page that show all projects in continuum. Ok is simple features! But i did those steps below and didn´t work. *Download : svn co http://svn.apache.org/repos/asf/maven/continuum/trunk/ continuum *Install jars of sun that was needed. *Did my changes. *mvn install in parent pom. Executed with sucess. Now how put it to work? I tried this too: cd continuum-plexus-application m2 -Denv=production assembly:assembly and happened the error: [ERROR] BUILD ERROR [INFO] [INFO] Cannot find lifecycle mapping for packaging: 'plexus-application'. Component descriptor cannot be found in the component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingplexus-application. -- Lucas Gonçalves Tel: (31)87382096 -- jesse mcconnell [EMAIL PROTECTED]
Re: I´m lost in the architecture
the trunk has the conversion from -web to the -webapp where -webapp is now using webwork for the UI layer...-web will be removed from trunk once folks are comfortable that the conversion is complete :) For example, the -web still has all the places that authorization is used to toggle display of ui elements. ie, don't bother with -web, if you look at the modules of the top lvl pom you'll notice it isn't built anymore jesse On 8/30/06, Lucas Gonçalves [EMAIL PROTECTED] wrote: I forgot explain that i changed continuum-webapp. Why there is too projects, continuum-web and continuum-webapp? Sorry i´m asking this but i´d never read about plexus... On 8/30/06, Lucas Gonçalves [EMAIL PROTECTED] wrote: First of all, sorry about my English! I need some features. In a resultbuild page of the projects a need know the revision(svn) from the build was done. Second i need to put the link of project´s site in main page, the page that show all projects in continuum. Ok is simple features! But i did those steps below and didn´t work. *Download : svn co http://svn.apache.org/repos/asf/maven/continuum/trunk/ continuum *Install jars of sun that was needed. *Did my changes. *mvn install in parent pom. Executed with sucess. Now how put it to work? I tried this too: cd continuum-plexus-application m2 -Denv=production assembly:assembly and happened the error: [ERROR] BUILD ERROR [INFO] [INFO] Cannot find lifecycle mapping for packaging: 'plexus-application'. Component descriptor cannot be found in the component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingplexus-application. -- Lucas Gonçalves Tel: (31)87382096 -- Lucas Gonçalves Tel: (31)87382096 -- jesse mcconnell [EMAIL PROTECTED]
Re: rbac role/operation/permission example allocation
basically that first bit are the roles that can be assigned to user on a per repository or per project basis as indicated by the (per repo) and (per project) tags. below that are the operations that are inclosed in corresponding permissions for that repo/project. The roles were based off your previous mail on the topic, and the operations I pulled out of your comments on potential roles. So there are three core entities that can have permissions wrapped around them, the administration of the application, each repository, and each project. jesse On 9/3/06, Brett Porter [EMAIL PROTECTED] wrote: Jesse, I've got some other things to do so I'll review this properly tomorrow, but I was wondering if you could explain the structure of the information at the start? - Brett On 02/09/2006, at 12:29 PM, Jesse McConnell wrote: Archiva Administration Roles: Administrator * add-index * regenerate-index * remove-index * modify-index * toggle-service Repository Roles (per repo): Repository Observer * view-reports Repository Maintainer * Repository Observer + * generate-reports * add-index * remove-index * modify-index * regenerate-index * generate-checksums Project Roles (per project): Project Observer * download-artifact * download-metadata Project Maintainer * Project Observer + * add-artifact * add-metadata * remove-artifact * remove-metadata * modify-artifact * modify-metadata * generate-checksums Operations: add-index regenerate-index remove-index modify-index toggle-service [turn off service to the site for maintaince, etc] view-reports generate-reports add-artifact remove-artifact modify-artifact download-artifact add-metadata remove-metadata modify-metadata download-metadata generate-checksums REPOSITORY/PROJECTS: RBAC does permission checks based on an object that a particular operation is trying to be invoked for or on. To maintain obtain common object that is fine grained enough for use with archiva the idea is to use a tuple of repository and project to describe a particular object that an operation is being associated with. Note, the binding of an operation and an object is a permission and that permission is in turn associated with one or more roles. The use of a wildcard or keyword can be used to denote that a particular operation applies to all items that match the wildcard pattern. The notation for a permission is P(OPERATION, OBJECT). For example: P( download-artifact, *-jpox ); This permission would grant the role the ability to download jpox artifacts from all repositories being managed. P( generate-checksum, central-* ); This permission would grant the role the ability to generate checksums for all projects in the repository known as central. P( generate-checksums, central-org.maven.apache.* ); This permission would grant the role the ability to generate checksums for all projects with a group id of at least org.maven.apache on the central repository. RBAC Administration: While it is certainly possible to dynamically generate roles and assoicate those roles with permissions it is probably best at this point to attempt to work out a feasible list of jobs and link up the permissions appropriately. We can easily generate the project maintainer and project obverser roles automatically on the creation of a given project and the same goes for linking up another repository. It is simply a matter of knowing what the permission assignments are configured like for a given role and replicating the role as needed and tweaking the name accordingly. When the time comes to dynamically modify permissions and roles the interface can be made quite simple, for example with the assigning of the generate-checksums operation it could be two drop down boxes, the first containing [central, snapshots, all] and the second containing the projects [org, org.apache, org.apache.maven, jpox, jdo, junit, all] Ultimately the point is that with RBAC great care is taken in working out structure of roles, permissions, and operations. The objects part of the puzzle is largely up the implementation and user of the system. -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: build timeouts
+1 plus I know that we would really like to be able to see the schedule of builds, I have a placeholder on the group summary page for Next Scheduled Build :) nice job kenney jesse On 9/3/06, Brett Porter [EMAIL PROTECTED] wrote: On 03/09/2006, at 12:08 AM, Kenney Westerhof wrote: For now I'll just add a field to the Schedule, stating max execution time of a build. +1, with the default being rather large (but not infinite). Sounds like we've got some work to do on the scheduling in the next release :) -- Kenney -- jesse mcconnell [EMAIL PROTECTED]
Re: plexus-security and archiva trunk
ok, after a couple of hectic days working on plexus-security and archiva in tandem joakim and I ironed out the remaining issue that we know of dealing with login issues and a host of other weird strangeness that was cropping up. The root cause was plexus security ui actions were not getting set as per-lookup. Now the pom.xml's were setup right for this behavior but we were not specifically setting the version of the plexus-maven-plugin in the plexus-security pom so we were getting a version of it that blissfully (and silently) ignored the settings in the pom.xml and was merrily creating our components without setting the instantiation strategy, which of course was a 'bad thing' (tm). Getting that going right appears to have resolved the issues that patrick of webwork fame referred to as 'funky' in our irc conversations on the matter. kudos to joakim and patrick on this btw for helping get it resolved. :) Barring a few issues in the user management pages which I am taking care of now (which btw are being purposefully kept simple atm for eventual plexus-user-management action integration) I think we are in relatively decent shape in regards to UI lvl authorization checking. Joakim is working on webdav security on archiva right now and should that go well I think I would like to nominate him for commit access to archiva since he is already a committer on continuum, maven-share, and maven-plugins and has been quite active in this endeavor. I know I am a relatively new committer to archiva myself so not sure about the protocol for that...but that's mostly a separate mail :P anyway, give the trunk of archiva a whirl and file security issues on it for me. I am going to focus on cleaning up some annoyances that I left in from the last little bit and then work on the next phase of security integration. cheers! jesse On 9/11/06, Jesse McConnell [EMAIL PROTECTED] wrote: well, committing my latest on the plexus-security integration and archiva trunk in a little bit and thought I would write a bit about it. it works! mostly... I have deployed the latest snapshots for plexus security so all of that should be fine, if there are problems ping me and I'll make sure all the snapshots are up. The user management pages need some work, but the basics are all in place. When you start it up I would recommend you go to the login/register link in the upper left corner. From here register for an account and then login right after that (need a success message there) and then click on the Settings link in the upper left corner near your name. This takes you to the user page where you can for a limited time only promote yourself to System Administrator! :) This will enable many of the links that I have wrapped up to show they are done. The Edit User link on the users page is a good one to look at, as well as the administration page (index.jsp) couple of things that need to get wrapped up asap logging out isn't working test the adding of repositories and the autogeneration of the Maintainer and Observer repository roles For the time being you can look in the DefaultRoleManager component in the webapp for the breakdown of operations, permissions and role creation. The operations in the initialize there are what would be placed in the permission= of the pss:ifAuthorized jsp tags. It is using Rahul's user manager authenticator, a jdo user manager and a jdo rbac store. jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: svn commit: r447983 - /maven/archiva/trunk/archiva-webapp/src/main/resources/xwork.xml
well, is that what we want? I have seen it go both ways. maybe we could make it an option configurable in the application.xml configuration or something.. but ya, we can do that. joakim? see any issues with that? jesse On 9/19/06, Brett Porter [EMAIL PROTECTED] wrote: Shouldn't the registration action actually log you in without prompting, then redirect to browse? On 20/09/2006, at 7:43 AM, [EMAIL PROTECTED] wrote: Author: jmcconnell Date: Tue Sep 19 14:43:10 2006 New Revision: 447983 URL: http://svn.apache.org/viewvc?view=revrev=447983 Log: fix the redirect on registration to go to the login page as opposed to the browse page Modified: maven/archiva/trunk/archiva-webapp/src/main/resources/xwork.xml Modified: maven/archiva/trunk/archiva-webapp/src/main/resources/ xwork.xml URL: http://svn.apache.org/viewvc/maven/archiva/trunk/archiva- webapp/src/main/resources/xwork.xml? view=diffrev=447983r1=447982r2=447983 == --- maven/archiva/trunk/archiva-webapp/src/main/resources/xwork.xml (original) +++ maven/archiva/trunk/archiva-webapp/src/main/resources/xwork.xml Tue Sep 19 14:43:10 2006 @@ -64,8 +64,14 @@ result name=security-login-success type=redirect- actionbrowse/result result name=security-login-cancel type=redirect- actionbrowse/result result name=security-logout type=redirect- actionbrowse/result - result name=security-register-success type=redirect- actionbrowse/result - result name=security-register-cancel type=redirect- actionbrowse/result + result name=security-register-success type=redirect- action +param name=actionNamelogin/param +param name=namespace/security/param + /result + result name=security-register-cancel type=redirect-action +param name=actionNamelogin/param +param name=namespace/security/param + /result result name=security-account-success type=redirect- actionbrowse/result result name=security-account-cancel type=redirect- actionbrowse/result -- jesse mcconnell [EMAIL PROTECTED]
Re: remove continuum-web on trunk?
the only reason I could see keeping it around was to make sure the security bits and pieces were all wrapped correctly...but since so much of that has changed with the project grouping and recent development in general... +1 On 9/26/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: +1 Emmanuel Brett Porter a écrit : subject says it all... any objections? continuum-webapp seems in adequate shape. -- jesse mcconnell [EMAIL PROTECTED]
[vote] rbac-integration branch merge to trunk
Brett suggested we do a vote for this today so I figured I would just do that now. [-1/0/+1] vote will be open for 72 hours Pulling from the other mail, this branch was pulled a bit over a week ago to test out the plexus-security integration with continuum. Some of the added features are * full separation between application webapp and security (lightweight integration). * proper modularization for security components (authentication, authorization, policy, system, web, etc...) * rbac (role based access control) authorization provider. * full user management war overlay (using healthy chunk of maven-user to make it happen) * toggle-able guest user authorization. * remember me and single sign on authentication. * forced admin account creation (through use of interceptor) * key based authentication (remember me, single sign on, new user validation emails, and password resets). * http auth filters (basic and digest). * aggressive plexus utilization. * aggressive xwork / webwork integration. * xwork interceptors for force admin, auto login (remember me), secured action, and environment checks. * secured actions for all of the /security namespace and at least one continuum secured action (these are enforced by the pssSecureActionInterceptor) * all the password validation, user management stuff (again maven-user origins) * continuum-security artifact containing the actual static and dynamic roles, and a continuum role manager that merges permissions to the core system, user, and guest users * ifAuthorized, ifAnyAuthorized, elseAuthorized jsp tags. * placeholders for ldap authentication, authorization and user details retrieval using plexus ldap components * ability to re-use Acegi for authentication +1 from me cheers, jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: Testing Harness release
I think some docs need to be added and a mess of the maven stub usages migrated from where they exist inside various pluging into this artifact...I wouldn't say its close to release from that standpoint. maybe someone else thinks differently, thats my 2 cents jesse On 10/5/06, Brian E. Fox [EMAIL PROTECTED] wrote: I'm getting close to calling for a maven-dependency-plugin release, but I'm using the current snapshot of the harness. Is this close to releasable? If not, then I may just move any required code internal to dependency since it's not heavily used. -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] commit access for henri yandell
belated +1 :) On 10/12/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hey, Cool, I will setup access for Henri now. Jason. On 12 Oct 06, at 7:14 AM 12 Oct 06, Kenney Westerhof wrote: +1 Arnaud HERITIER wrote: +1 Arnaud On 10/11/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, I'm here at ApacheCon with Henri and he's helping a lot with archiva doco and helping me clean up the sync. I'd just like to give him access so he can help us. +1 Jason. -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] rbac-integration branch merge to trunk
this has been merged to trunk now, time to start plotting a path to 1.1 release :) On 10/6/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 6 Oct 06, at 11:42 AM 6 Oct 06, Jesse McConnell wrote: summary: +1 - 8 binding would be 5 I think.. 3 is all you need with no -1s. So I'll get this merged over in the next couple of days, probably early next week actually, there are some jsp integration issues that will have to take place from what I have heard. but we'll integrate this over to trunk asap, jesse On 10/4/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: Jesse McConnell wrote: Brett suggested we do a vote for this today so I figured I would just do that now. [-1/0/+1] vote will be open for 72 hours +1 -- Trygve -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Continuum webapp error on accessing any page
(CompositionPhase.java:31) ... 71 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Unable to lookup component 'org.codehaus.plexus.security.policy.SingleSig nOnSettings', it could not be started at org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:86) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:247) at org.codehaus.plexus.component.composition.CompositionUtils.findRequirement(CompositionUtils.java:87) ... 76 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLifecycleException: Error starting component at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:114) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:100) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:77) ... 78 more Caused by: org.codehaus.plexus.personality.plexus.lifecycle.phase.PhaseExecutionException: Unable to auto-configure component at org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhase.execute(AutoConfigurePhase.java:48) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:102) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:110) ... 81 more Caused by: org.codehaus.plexus.component.configurator.ComponentConfigurationException: Cannot find autowire nor field in org.codehaus.plexus.security.policy.Defa ultSingleSignOnSettings for 'cookieDomain' at org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.init(ComponentValueSetter.java:68) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:131) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) at org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:54) at org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:47) at org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhase.execute(AutoConfigurePhase.java:39) ... 83 more -- jesse mcconnell [EMAIL PROTECTED]
contents of a 1.1 release
I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object and add/modify in the profile concepts into the store then we really ought to clean up the whole store api which is more painful to work with then it really should be. joakim and I had a lot of success with structuring things nicely in the plexus-security jdo stores and we could probably apply a ton of the concepts there in terms of api to the continuum-store and make it scads easier to work with. and on and on. I agree with Emmanuel that since 1.1 as it currently stands is not backwards compatible (I think) with the old database we ought to just add in what we need now...But doing this will definitely move out a 1.1 release into the new year...and is that something we want to do? I dunno really, personally I would be cool with adding in profiles and refactoring the core chunks of continuum up now and get it over with, but does anyone else have anything to say on the matter? I know we have had a lot more interest recently by folks like rahul and christian on participating, would you guys be interested in taking on some of these challenges with us? Theres nothing like ripping through the guts of code to really get involved :) thoughts? should we open this out to the users list maybe? jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] Access to documentation for Wendy Smoak
+1 oh ya, totally On 10/16/06, John Casey [EMAIL PROTECTED] wrote: sorry for the late vote, but I'm +1 as well! :-) -john On 10/15/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, Wendy you now have access to the site: http://svn.apache.org/repos/asf/maven/site/trunk/ And I've sent you instructions for getting access to main Confluence Wiki. Jason. On 15 Oct 06, at 5:07 AM 15 Oct 06, Vincent Massol wrote: +1 -Vincent -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: samedi 14 octobre 2006 19:42 To: Maven Developers List Subject: [vote] Access to documentation for Wendy Smoak Hi, Wendy Smoak, from the Struts project, has kindly offered to help with our documentation. She wants to make the links to the Wiki more prominent and generally help with usability. I would like to give her access to our main Wiki and the site module so she can help without restriction. I don't think there is any downside in letting Apache committers who are using Maven to have access to our documentation. +1 Jason. __ _ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - 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] -- jesse mcconnell [EMAIL PROTECTED]
Re: SNAPSHOT policy
both are valid approaches in my book. freebsd tracks things like that, where 6-stable is the latest stable stuff on the trunk and releases are cut off of that tag (RELENG_6 really I think). I have mentioned this before as one of the release strategies that ought to be supported but I think there are bigger fish to fry atm. Meaning the current setup works for this, you just need to adjust for it manually I believe, the release plugin will not guess your naming strategy. *-SNAPSHOT as Dennis mentions does mean something different in my book, where -SNAPSHOT is tacked on all the micro releases as well for development and a finer grained version management strategy. 2.1-SNAPSHOT could really get you into trouble if you are using it for 2.1.0, 2.1.1, 2.1.2, 2.1.3, etc...any kinda api change in there and you'll be having a harder time tracking down what updated dependency module might not have had the latest snapshot deployed. cheers, jesse On 10/18/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Jörg Schaible wrote: Hi Dennis, Dennis Lundberg wrote: [snip] == --- maven/plugins/trunk/maven-clean-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-clean-plugin/pom.xml Mon Oct 16 10:55:07 2006 @@ -9,7 +9,7 @@ artifactIdmaven-clean-plugin/artifactId packagingmaven-plugin/packaging nameMaven Clean Plugin/name - version2.1.1/version + version2.1-SNAPSHOT/version This doesn't seem right. After version 2.1.1 comes version 2.1??? snip What's wrong with this in general? We do this all the time! 2.1-SNAPSHOT means for us always the latest version from the 2.1-trunk and from time to time, we have a release, i.e. 2.1.0, 2.1.1, 2.1.2, ... - Jörg Not in my book. To me 2.1-SNAPSHOT means something that will be called 2.1 when it will be released. If you are on a 2.1.0, 2.1.1 , 2.1.2 course, then the next upcoming release is 2.1.3. The version number in the pom should therefor be 2.1.3-SNAPSHOT -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Continuum behind SSL, any progress on this
There are still a number of things being worked on, but I imagine after we pull the web testing back into the fold we can release an alpha or something along those lines while the rest is fixed/polished up for a release. the trunk has been pretty useful for a while so there shouldn't be any problems grabbing and building the latest from source, its pretty easy to deploy now that its a webapp. Note, if you are building on windows there is a strange issue intermittently cropping up in the release functionality that is getting nailed down so you might want to compile with -Dmaven.test.skip=true jesse On 10/18/06, Jorg Heymans [EMAIL PROTECTED] wrote: Carlos Sanchez wrote: I think this is already fixed for 1.1 Are you guys planning on releasing a first 1.1 snapshot anytime soon? Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum WAR snapshot - installation instructions anywhere?
Graham, if you confirm you have it working just get me the settings
your using and I get the readme updated with it.
thanks,
jesse
On 10/19/06, Brett Porter [EMAIL PROTECTED] wrote:
For Jetty, look in jetty-env.xml in the webapp.
For Tomcat, I think it's this (derived from my plexus configuration
for the naming component, should match Tomcat though):
Resource
namejdbc/users/name
typejavax.sql.DataSource/type
properties
property
namedriverClassName/name
valueorg.apache.derby.jdbc.EmbeddedDriver/value
/property
property
nameurl/name
valuejdbc:derby:${plexus.home}/database/
users;create=true/value
/property
property
nameusername/name
valuesa/value
/property
property
namepassword/name
value/value
/property
/properties
/Resource
Resource
namejdbc/continuum/name
typejavax.sql.DataSource/type
properties
property
namedriverClassName/name
valueorg.apache.derby.jdbc.EmbeddedDriver/value
/property
property
nameurl/name
valuejdbc:derby:${plexus.home}/database/
continuum;create=true/value
/property
property
nameusername/name
valuesa/value
/property
property
namepassword/name
value/value
/property
/properties
/Resource
On 20/10/2006, at 12:08 AM, ben short wrote:
well it should be pretty easy...
Assuming you know how to setup a deaby server and how to create
databases then you just need to change the driver class and url of
each resource and you should be in busness.
Ben
On 10/19/06, Graham Leggett [EMAIL PROTECTED] wrote:
ben short wrote:
I used the admin webapp for tomcat 5.5 to create the following two
jndi resources.
jdbc/continuum
jdbc/users
This resulted in the following context being created in the
server.xml
Is there any easy to follow config out there that describes
setting up a
derby database with continuum? The tomcat docs include lots of
examples
for various external DBs, but none for small scale DBs.
Regards,
Graham
--
-
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]
--
jesse mcconnell
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] commit access for Dan Fabulich
+1 On 10/19/06, Kenney Westerhof [EMAIL PROTECTED] wrote: +1 Jason van Zyl wrote: Hi, Over the last month Dan has been helping a great deal with the Maven bootstrap and integration testing which are not for the faint of heart. He's been great at communicating solutions and has done a lot of work and submitted many patches to make our bootstrap and integration testing much easier to understand and use. He's created a simple Ant bootstrap mechanism, created a nice and clean integration testing setup and is working on a archetype for ITs to try and make it easier for others to contribute ITs. Dan also has many pending patches in JIRA for many other fixes and I wold like him to be able to integrate those himself. He's demonstrated to me that he understands Maven very well and is great to work with so I'd like to invite him to the team. +1 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] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] commit access for Dan Fabulich
I think we should nominate him for sainthood too. :-) pretty sure that is a different mailing list...:P On 10/19/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, Over the last month Dan has been helping a great deal with the Maven bootstrap and integration testing which are not for the faint of heart. He's been great at communicating solutions and has done a lot of work and submitted many patches to make our bootstrap and integration testing much easier to understand and use. He's created a simple Ant bootstrap mechanism, created a nice and clean integration testing setup and is working on a archetype for ITs to try and make it easier for others to contribute ITs. Dan also has many pending patches in JIRA for many other fixes and I wold like him to be able to integrate those himself. He's demonstrated to me that he understands Maven very well and is great to work with so I'd like to invite him to the team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
project group shortcuts
last week I mentioned this in rahul's zero-conf mail if this is really what we want to change here then perhaps we ought to make it an option for configuration of the project group in all cases, the ability to specify the name of the project group...or give it some kinda short identification element. I kinda like that idea, then we can use 'Doxia' for 'The Doxia Project' and we can even use the short user input project group Id in the urls... to do this I would put a textfield on the project group creation screens and then an edittable one in the project config screens, and add it to the model. This shortcut would replace the locations where the projectGroupName is currently being passed around on actions to let projects know what group is being interacted with. Api changes obviously to support this as well, but I don't think this would be too terribly bad to get into place. We get to avoid passing around the jdo projectGroupId values which might get screwy with clustering if we have different stores and the project groups are not in sync. We would also be able to do some mapping to allow for direct url friendly linking to the summary pages http://ci.goo.org:9090/Doxia which would go to the groupSummary page for the Doxia project. Does anyone have any objections to adding this functionality? It would clean up the interactions for the webwork actions dealing with project names (having The Doxia Project passed around on the url's is kinda chintz) not to mention allow the m1/m2/ant/shell project groups have a consistent way to referring to the project group concept. I can see a lot of bonuses and no downsides right now...I think it will clean up a lot of different interactions. jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: svn commit: r470106 - in /maven/continuum/trunk/continuum-model/src/main: java/ mdo/continuum.xml
hm, good point
I'll look for the option that turns that off in the jdo stuff
jesse
On 11/1/06, Emmanuel Venisse [EMAIL PROTECTED] wrote:
A database table will be created for this class.
Emmanuel
[EMAIL PROTECTED] a écrit :
Author: jmcconnell
Date: Wed Nov 1 13:29:24 2006
New Revision: 470106
URL: http://svn.apache.org/viewvc?view=revrev=470106
Log:
remove the java file from the model project and generate via modello like all
the others
Removed:
maven/continuum/trunk/continuum-model/src/main/java/
Modified:
maven/continuum/trunk/continuum-model/src/main/mdo/continuum.xml
Modified: maven/continuum/trunk/continuum-model/src/main/mdo/continuum.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-model/src/main/mdo/continuum.xml?view=diffrev=470106r1=470105r2=470106
==
--- maven/continuum/trunk/continuum-model/src/main/mdo/continuum.xml
(original)
+++ maven/continuum/trunk/continuum-model/src/main/mdo/continuum.xml Wed Nov
1 13:29:24 2006
@@ -1181,5 +1181,69 @@
/field
/fields
/class
+
+class
+ nameContinuumProjectState/name
+ packageNameorg.apache.maven.continuum.project/packageName
+ version1.0.0+/version
+ fields
+field
+ namename/name
+ version1.0.0+/version
+ typeString/type
+/field
+ /fields
+ codeSegments
+codeSegment
+ version1.0.0+/version
+ code![CDATA[
+public final static int NEW = 1;
+public final static int OK = 2;
+public final static int FAILED = 3;
+public final static int ERROR = 4;
+public final static int BUILDING = 6;
+public final static int CHECKING_OUT = 7;
+public final static int UPDATING = 8;
+public final static int WARNING = 9;
+public final static int CHECKEDOUT = 10;
+
+// TODO: maybe move these to another class
+public static final int TRIGGER_FORCED = 1;
+
+// TODO: remove
+public static final int TRIGGER_SCHEDULED = 0;
+
+public static final int TRIGGER_UNKNOWN = TRIGGER_SCHEDULED;
+
+public String getI18nKey()
+{
+return org.apache.maven.continuum.project.state. + name;
+}
+
+public boolean equals( Object object )
+{
+if ( !( object instanceof ContinuumProjectState ) )
+{
+return false;
+}
+
+ContinuumProjectState other = (ContinuumProjectState) object;
+
+return name.equals( other.name );
+}
+
+public int hashCode()
+{
+return name.hashCode();
+}
+
+public String toString()
+{
+return name;
+}
+ ]]/code
+/codeSegment
+ /codeSegments
+/class
/classes
/model
--
jesse mcconnell
[EMAIL PROTECTED]
build scheduling issues
I was reading through the DefaultContinuum.buildProjects( Schedule id ) method and after discussing some things with Emmanuel...I think we have a problem here. When I went through and refactored things to support a more Project Group centric setup with continuum I changed this method a bit. Originally, this method would gather up all projects that would be triggered by that schedule, run them all through the project sorter and then build each in sequence. When I added the project groups to this mix, I changed things to be on a project group basis, so that on a project group by project group basis it would order the projects and build them. At the time I thought this was the way to go...but maybe not. 17:14 evenisse we need to take all projects from all groups, sort them 17:15 evenisse if we don't have a cycle, it's ok and we build all 17:15 evenisse if it isn't ok, we sort project by group For example, if we loaded up a Plexus group and a Maven group...the way it currently is (with my change) it would process all triggered builds within one group and then process all triggered builds in the other group. This would not take into account potential dependencies between the two. Does anyone have any thoughts on this? I am inclined to fix it up so its like it used to be where all projects across all project groups are thrown into the graphI keep feeling like I am missing something wrong with this, but I can't pin it down. One thing that perhaps Emmanuel could explain a bit more is the third comment there. In our conversation on this he said that he thinks that the cycles are cropping up all the time, and if thats the case then we are building a lot of unordered builds which would account for some of the strange reports we have been getting. Are you saying that if we detect the cycle we default back to the way I am doing it now? order within the groups... jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: build scheduling issues
we should add a page that analyzes each schedule for cycles...that would be a cool little feature On 11/8/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: Yes, we need a global ordering, so projects will be build independently of groups, because in some case a cycle can be created between groups (not necessary between projects). In case a cycle is detected between projects, continuum can't find the build order. In this case, I think we need to sort a little project so will reduce build errors. So if we have a cycle, we can sort projects in a group and build them. In most of case (maven projects), we don't have a cycle in a group. Emmanuel Brett Porter a écrit : I think you want global ordering. Grouping should just be a display/management technique, not anything that changes how projects are handled. However, this needs to be reviewed as a whole (which I think Emmanuel is doing), such that builds can be triggered when their dependencies change which will help with the ordering as it won't be dependant on them all being triggered at the same time? - Brett On 08/11/2006, at 9:51 AM, Jesse McConnell wrote: I was reading through the DefaultContinuum.buildProjects( Schedule id ) method and after discussing some things with Emmanuel...I think we have a problem here. When I went through and refactored things to support a more Project Group centric setup with continuum I changed this method a bit. Originally, this method would gather up all projects that would be triggered by that schedule, run them all through the project sorter and then build each in sequence. When I added the project groups to this mix, I changed things to be on a project group basis, so that on a project group by project group basis it would order the projects and build them. At the time I thought this was the way to go...but maybe not. 17:14 evenisse we need to take all projects from all groups, sort them 17:15 evenisse if we don't have a cycle, it's ok and we build all 17:15 evenisse if it isn't ok, we sort project by group For example, if we loaded up a Plexus group and a Maven group...the way it currently is (with my change) it would process all triggered builds within one group and then process all triggered builds in the other group. This would not take into account potential dependencies between the two. Does anyone have any thoughts on this? I am inclined to fix it up so its like it used to be where all projects across all project groups are thrown into the graphI keep feeling like I am missing something wrong with this, but I can't pin it down. One thing that perhaps Emmanuel could explain a bit more is the third comment there. In our conversation on this he said that he thinks that the cycles are cropping up all the time, and if thats the case then we are building a lot of unordered builds which would account for some of the strange reports we have been getting. Are you saying that if we detect the cycle we default back to the way I am doing it now? order within the groups... jesse --jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: svn commit: r473012 - /maven/continuum/trunk/continuum-webapp/pom.xml
point me where and I'll add it, but I just did a quick search in continuum and saw it referenced in the WorkingCopyAction so threw in the in pom jesse On 11/9/06, Christian Edward Gruber [EMAIL PROTECTED] wrote: Doesn't the plexus-runtime need it too? Christian. [EMAIL PROTECTED] wrote: Author: jmcconnell Date: Thu Nov 9 10:39:25 2006 New Revision: 473012 URL: http://svn.apache.org/viewvc?view=revrev=473012 Log: added activation dependency, it appears that WorkingCopyAction brings in this dependency so it ought to be marked as such, thanks to graham for noticing this Modified: maven/continuum/trunk/continuum-webapp/pom.xml Modified: maven/continuum/trunk/continuum-webapp/pom.xml URL: http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/pom.xml?view=diffrev=473012r1=473011r2=473012 == --- maven/continuum/trunk/continuum-webapp/pom.xml (original) +++ maven/continuum/trunk/continuum-webapp/pom.xml Thu Nov 9 10:39:25 2006 @@ -416,5 +416,11 @@ artifactIdcommons-lang/artifactId version2.1/version /dependency +dependency + groupIdjavax.activation/groupId + artifactIdactivation/artifactId + version1.1/version + scopeprovided/scope +/dependency /dependencies /project -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023* -- jesse mcconnell [EMAIL PROTECTED]
jira components
The current components in jira are (with current # of categoried issues): AOL Notifier 1 Core system 80 Database16 Documentation 12 IRC Notifier3 Jabber Notifier 3 Mail Notifier 14 MSN Notifier2 Notification5 Project Grouping1 SCM 18 Web interface 107 XMLRPC Interface12 No Component61 I would like to propose reorganizing these a little bit, combining all of the Notifiers into the Notification component. Also add a component for the different integrations for issues related to Ant/Shell/M1 and M2 integrations, I think they are currently mostly getting split out between Web Interface and Core system. We also might be well served by breaking out the web interface into components: Web - Security, Web - Notification, Web - Groups, Web - Projects, Web - Other. thoughts? jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: jira components
well thats a little more verbose then I was looking for, I was thinking we could shove all the tool integration stuff together, and all the notifiers together. I was envisioning Core system 80 Database 16 Documentation 12 Tool Integration Notification 5 SCM 18 Web UI 89 Web Security 0 Web Groups 13 Web Projects 9 Web Configuration 2 XMLRPC Interface12 No Component 61 Web seems to be the noisiest so breaking it out a bit might help, but the others could be consolidated to make it easier for people assigning issues initially to hit the right side of the right barn. jesse On 11/10/06, Joakim Erdfelt [EMAIL PROTECTED] wrote: Breaking apart the notifiers are a good idea. However, due to natural language sort, they are not grouped very efficiently. How about Notifier ___ instead? So, expanding your ideas to a the eventual list, we wind up with ... Core system 80 Database 16 Documentation 12 Integration M20 Integration M10 Integration Ant0 Integration Shell 0 Notification Subsystem 5 Notifier (AOL) 1 Notifier (IRC) 3 Notifier (Jabber) 3 Notifier (Mail) 14 Notifier (MSN) 2 Notifier (Wagon) 0 Project Grouping 1 SCM 18 Web UI 89 Web Security 0 Web Groups 13 Web Projects 9 Web Configuration 2 XMLRPC Interface12 No Component 61 Looks detailed. ;-) - Joakim Jesse McConnell wrote: The current components in jira are (with current # of categoried issues): AOL Notifier 1 Core system 80 Database 16 Documentation 12 IRC Notifier 3 Jabber Notifier 3 Mail Notifier 14 MSN Notifier 2 Notification 5 Project Grouping 1 SCM 18 Web interface 107 XMLRPC Interface 12 No Component 61 I would like to propose reorganizing these a little bit, combining all of the Notifiers into the Notification component. Also add a component for the different integrations for issues related to Ant/Shell/M1 and M2 integrations, I think they are currently mostly getting split out between Web Interface and Core system. We also might be well served by breaking out the web interface into components: Web - Security, Web - Notification, Web - Groups, Web - Projects, Web - Other. thoughts? jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: jira components
well, when you look at it like that... ok, I'll do that this weekend and try and get a home for those poor 61 lonely issues :) jesse On 11/10/06, Brett Porter [EMAIL PROTECTED] wrote: I think breaking out the tools and notifiers is a good idea. They are actually the *easiest* ones for people to hit because they know which specific one they are using. How about breaking up core system into scheduling, etc? Also, is there anything in those 61 no components that should be a new component? - Brett On 11/11/2006, at 6:41 AM, Jesse McConnell wrote: well thats a little more verbose then I was looking for, I was thinking we could shove all the tool integration stuff together, and all the notifiers together. I was envisioning Core system 80 Database 16 Documentation 12 Tool Integration Notification 5 SCM 18 Web UI 89 Web Security 0 Web Groups 13 Web Projects 9 Web Configuration 2 XMLRPC Interface12 No Component 61 Web seems to be the noisiest so breaking it out a bit might help, but the others could be consolidated to make it easier for people assigning issues initially to hit the right side of the right barn. jesse On 11/10/06, Joakim Erdfelt [EMAIL PROTECTED] wrote: Breaking apart the notifiers are a good idea. However, due to natural language sort, they are not grouped very efficiently. How about Notifier ___ instead? So, expanding your ideas to a the eventual list, we wind up with ... Core system 80 Database 16 Documentation 12 Integration M20 Integration M10 Integration Ant0 Integration Shell 0 Notification Subsystem 5 Notifier (AOL) 1 Notifier (IRC) 3 Notifier (Jabber) 3 Notifier (Mail) 14 Notifier (MSN) 2 Notifier (Wagon) 0 Project Grouping 1 SCM 18 Web UI 89 Web Security 0 Web Groups 13 Web Projects 9 Web Configuration 2 XMLRPC Interface12 No Component 61 Looks detailed. ;-) - Joakim Jesse McConnell wrote: The current components in jira are (with current # of categoried issues): AOL Notifier 1 Core system 80 Database 16 Documentation 12 IRC Notifier 3 Jabber Notifier 3 Mail Notifier 14 MSN Notifier 2 Notification 5 Project Grouping 1 SCM 18 Web interface 107 XMLRPC Interface 12 No Component 61 I would like to propose reorganizing these a little bit, combining all of the Notifiers into the Notification component. Also add a component for the different integrations for issues related to Ant/Shell/M1 and M2 integrations, I think they are currently mostly getting split out between Web Interface and Core system. We also might be well served by breaking out the web interface into components: Web - Security, Web - Notification, Web - Groups, Web - Projects, Web - Other. thoughts? jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] releasing archetype bundles
+1 archetype updates are definitely a good thing at this point :) jesse On 11/28/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/28/06, Jason van Zyl [EMAIL PROTECTED] wrote: I don't think this requires 72 hours as I just want to release a bunch of Archetypes. I want to release them all. If no one objects I'll release them all at the end of the day. I doubt getting three PMC member votes will be a problem, but you do need them-- lazy consensus does not work for release votes. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Remote Resources Plugin / JavaDoc Plugin / Source Plugin
I like it, nice way to solve the problem I think. I notice the javadoc plugin also addresses a problem I had with it a couple of months ago so I am all for releasing it. +1 jesse On 11/29/06, Jason van Zyl [EMAIL PROTECTED] wrote: I have fixed all the headers and checked them in. jason. On 29 Nov 06, at 6:54 PM 29 Nov 06, Joakim Erdfelt wrote: Once the headers are fixed, +1 - Joakim Daniel Kulp wrote: Jason, The files still don't have the proper Apache header on them. You added the old style (with the copyright date) instead of the new style documented at: http://www.apache.org/legal/src-headers.html Those need to change. Also, the pom.xml files need to have the header as well. Note: there is a bug in maven/jdom that may discard the header at deploy time. Thus, it may need to go INSIDE the project tag. The other files in src also need it (fml/faq.fml for example, possibly the properties files as well). Dan On Wednesday November 29 2006 10:38 am, Jason van Zyl wrote: Hi, This is a group release to attempt to deal with the licensing resources that need to be packaged up in all the archives we distribute. This is, in particular, and attempt to deal with the JARs we release. Namely the binary, source, and javadoc JARs we create with the JAR, Source, and JavaDoc plugins respectively. I have created the Remote Resources Plugin which is documented here: http://people.apache.org/~jvanzyl/maven-remote-resources-plugin/ And I have created a diagram of the process that is currently happening as a result of the changes I have made to the Source, and JavaDoc plugins: http://idisk.maven.org/jvanzyl/Public/RemoteResourcesHandling.png Essentially the remote resources plugins creates a directory of resources and modifies the POM at runtime so it carries with it the information about this directory. The other archiving plugins then look for this resource and insert it into the archives they create if found. Ideally the Resource element should have a unique id but the directory name will do for now. You can see here that I've created a profile which will enable the remote resources plugins and pull down the bundle that contains the standard license and notice files: http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml And I have deployed all the plugins above with this tool chain so you can see them here: http://people.apache.org/repo/m2-snapshot-repository/org/apache/ maven/ plugins/maven-remote-resources-plugin/1.0-SNAPSHOT/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ maven/ plugins/maven-source-plugin/2.0.2-SNAPSHOT/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ maven/ plugins/maven-javadoc-plugin/2.2-SNAPSHOT/ If I can release these plugins then I think we can solve most of the licensing/resource doldrums. 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] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release MWAR Plugin
yep yep +1 On 11/30/06, Andrew Williams [EMAIL PROTECTED] wrote: +1 Andy Vincent Siveton wrote: Late, but here's my +1 Vincent 2006/11/28, Stephane Nicoll [EMAIL PROTECTED]: +1 Stéphane On 11/28/06, John Tolentino [EMAIL PROTECTED] wrote: Hi Everyone, The latest version (2.0.2-SNAPSHOT) of the maven-war-plugin is now deployed to the snapshot repo. We'll also have the license stuff resolved before doing any release. For your reference of features included in this release: http://www.nabble.com/Planning-a-release-of-Maven-War-Plugin-tf2714187s177.html I now like to call a vote for Releasing the Maven WAR Plugin. Here's my +1. Thanks, John - 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] -- jesse mcconnell [EMAIL PROTECTED]
Re: continuum-webapp models
I think I added a couple of models since there had been precendent in there being other models in use and as a way to present data into the extreme components which needed objects presented in a certain fashion if we can do away with them without issues then I am for that :) jesse On 12/6/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: We can clean them. I don't think session-models is used. Emmanuel Brett Porter a écrit : anyone? On 01/12/2006, at 11:29 AM, Brett Porter wrote: I see a couple of models in continuum-webapp, which seem to be partially used. Does anyone know if session-models is used any more? What about view-models - only the summary parts still seem valid? - Brett -- jesse mcconnell [EMAIL PROTECTED]
Re: Maven 2.0.5-SNAPSHOT problem building continuum-release
ya, if you look through her debug output there is a big chunk where all the 2.0.4 deps are getting reverted to 2.0 just like in the error message below. it effected a number of the dependencies [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0.4 for project: null:maven-project:jar:2.0.4 from the repository. [DEBUG] org.apache.maven:maven-project:jar:2.0:compile (removed - nearer found: 2.0.4) [DEBUG] org.apache.maven:maven-project:jar:2.0.4:compile (selected for compile) [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0.4 for project: null:maven-settings:jar:2.0.4 from the repository. [DEBUG] org.apache.maven:maven-settings:jar:2.0.4:compile (removed - nearer found: 2.0) right there you see the project getting updated from 2.0 - 2.0.4 but on the next line you see maven-settings going from 2.0.4 - 2.0 she was on windows/cygwin btw jesse On 12/6/06, Wendy Smoak [EMAIL PROTECTED] wrote: I'm having trouble building Continuum with Maven 2.0.5-SNAPSHOT. I get a test error in continuum-release, and it seems to be due to Maven selecting the 2.0 version of maven-artifact instead of the 2.0.4 version. If I build with Maven 2.0.4, it works fine. If I add a dependency on maven-artifact 2.0.4 to the continuum-release pom as Jesse suggested trying, then it works with 2.0.5-SNAPSHOT. Here's the test report, and a link to mvn install -X output, including org.apache.maven:maven-artifact:jar:2.0.4:compile (removed - nearer found: 2.0) http://wiki.wsmoak.net/cgi-bin/wiki.pl?ContinuumRelease Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r483341 - in /maven/archiva/trunk/archiva-webapp/src/main: java/org/apache/maven/archiva/web/action/SearchAction.java resources/xwork.xml webapp/WEB-INF/jsp/quickSearch.jsp
I played around with this a while back and it appeared that the action
messages were getting dropped in the redirect strategy that we are
using in p-sec to get control back to the users application...
we should flag this as something to review though
jesse
On 12/6/06, Brett Porter [EMAIL PROTECTED] wrote:
Isn't there a way we can do this with an action message rather than
creating our own custom strings every time?
- Brett
On 07/12/2006, at 3:08 PM, [EMAIL PROTECTED] wrote:
Author: oching
Date: Wed Dec 6 20:08:03 2006
New Revision: 483341
URL: http://svn.apache.org/viewvc?view=revrev=483341
Log:
PR: MRM-246
Added display of error messages when an account is locked after 3
unsuccessful login attempts.
Modified:
maven/archiva/trunk/archiva-webapp/src/main/java/org/apache/
maven/archiva/web/action/SearchAction.java
maven/archiva/trunk/archiva-webapp/src/main/resources/xwork.xml
maven/archiva/trunk/archiva-webapp/src/main/webapp/WEB-INF/jsp/
quickSearch.jsp
Modified: maven/archiva/trunk/archiva-webapp/src/main/java/org/
apache/maven/archiva/web/action/SearchAction.java
URL: http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-
webapp/src/main/java/org/apache/maven/archiva/web/action/
SearchAction.java?view=diffrev=483341r1=483340r2=483341
==
--- maven/archiva/trunk/archiva-webapp/src/main/java/org/apache/
maven/archiva/web/action/SearchAction.java (original)
+++ maven/archiva/trunk/archiva-webapp/src/main/java/org/apache/
maven/archiva/web/action/SearchAction.java Wed Dec 6 20:08:03 2006
@@ -80,6 +80,8 @@
private static final String ARTIFACT = artifact;
+private String infoMessage;
+
public String quickSearch()
throws MalformedURLException, RepositoryIndexException,
RepositoryIndexSearchException,
ConfigurationStoreException, ParseException
@@ -184,5 +186,15 @@
public Collection getSearchResults()
{
return searchResults;
+}
+
+public String getInfoMessage()
+{
+return infoMessage;
+}
+
+public void setInfoMessage( String infoMessage )
+{
+this.infoMessage = infoMessage;
}
}
Modified: maven/archiva/trunk/archiva-webapp/src/main/resources/
xwork.xml
URL: http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-
webapp/src/main/resources/xwork.xml?
view=diffrev=483341r1=483340r2=483341
==
--- maven/archiva/trunk/archiva-webapp/src/main/resources/xwork.xml
(original)
+++ maven/archiva/trunk/archiva-webapp/src/main/resources/xwork.xml
Wed Dec 6 20:08:03 2006
@@ -76,7 +76,10 @@
!-- The following security-* result names arrive from the
plexus-security package --
result name=security-login-success type=redirect-
actionindex/result
result name=security-login-cancel type=redirect-
actionindex/result
- result name=security-login-locked type=redirect-
actionindex/result
+ result name=security-login-locked type=redirect-action
+param name=infoMessageAccount Locked/param
+param name=actionNameindex/param
+ /result
result name=security-logout type=redirect-actionindex/
result
result name=requires-authentication type=redirect-action
param name=actionNamelogin/param
Modified: maven/archiva/trunk/archiva-webapp/src/main/webapp/WEB-
INF/jsp/quickSearch.jsp
URL: http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-
webapp/src/main/webapp/WEB-INF/jsp/quickSearch.jsp?
view=diffrev=483341r1=483340r2=483341
==
--- maven/archiva/trunk/archiva-webapp/src/main/webapp/WEB-INF/jsp/
quickSearch.jsp (original)
+++ maven/archiva/trunk/archiva-webapp/src/main/webapp/WEB-INF/jsp/
quickSearch.jsp Wed Dec 6 20:08:03 2006
@@ -21,6 +21,10 @@
ww:head /
/head
+ww:if test=%{infoMessage != null}
+ p${infoMessage}/p
+/ww:if
+
body
h1Search/h1
--
jesse mcconnell
[EMAIL PROTECTED]
Re: [vote] release maven-dependency-tree
+1 On 12/7/06, Daniel Kulp [EMAIL PROTECTED] wrote: +1 now. (non-binding) Dan On Thursday 07 December 2006 17:43, Joakim Erdfelt wrote: This has been corrected in subversion. [maven-dependency-tree]$ mvn -PsharedResources clean package ...(snip) ... [maven-dependency-tree]$ jar -tvf target/maven-dependency-tree-1.0-SNAPSHOT.jar 0 Thu Dec 07 17:38:32 EST 2006 META-INF/ 125 Thu Dec 07 17:38:30 EST 2006 META-INF/MANIFEST.MF 0 Thu Dec 07 17:38:12 EST 2006 META-INF/plexus/ 0 Thu Dec 07 17:38:24 EST 2006 org/ 0 Thu Dec 07 17:38:24 EST 2006 org/apache/ 0 Thu Dec 07 17:38:24 EST 2006 org/apache/maven/ 0 Thu Dec 07 17:38:24 EST 2006 org/apache/maven/shared/ 0 Thu Dec 07 17:38:24 EST 2006 org/apache/maven/shared/dependency/ 0 Thu Dec 07 17:38:24 EST 2006 org/apache/maven/shared/dependency/tree/ 393 Thu Dec 07 17:38:12 EST 2006 META-INF/plexus/components.xml 11358 Thu Dec 07 17:38:12 EST 2006 META-INF/LICENSE.txt 619 Thu Dec 07 17:38:12 EST 2006 META-INF/NOTICE.txt 5982 Thu Dec 07 17:38:24 EST 2006 org/apache/maven/shared/dependency/tree/DefaultDependencyTreeBuilder.class 858 Thu Dec 07 17:38:24 EST 2006 org/apache/maven/shared/dependency/tree/DependencyTreeBuilder$1.class 1160 Thu Dec 07 17:38:24 EST 2006 org/apache/maven/shared/dependency/tree/DependencyTreeBuilder.class 1485 Thu Dec 07 17:38:24 EST 2006 org/apache/maven/shared/dependency/tree/DependencyTree.class 700 Thu Dec 07 17:38:24 EST 2006 org/apache/maven/shared/dependency/tree/DependencyTreeBuilderException.clas s 993 Thu Dec 07 17:38:24 EST 2006 org/apache/maven/shared/dependency/tree/DependencyNode.class 4833 Thu Dec 07 17:38:24 EST 2006 org/apache/maven/shared/dependency/tree/DependencyTreeResolutionListener.cl ass 0 Thu Dec 07 17:38:32 EST 2006 META-INF/maven/ 0 Thu Dec 07 17:38:32 EST 2006 META-INF/maven/org.apache.maven.shared/ 0 Thu Dec 07 17:38:32 EST 2006 META-INF/maven/org.apache.maven.shared/maven-dependency-tree/ 2933 Thu Dec 07 17:19:04 EST 2006 META-INF/maven/org.apache.maven.shared/maven-dependency-tree/pom.xml 136 Thu Dec 07 17:38:32 EST 2006 META-INF/maven/org.apache.maven.shared/maven-dependency-tree/pom.properties - Joakim Daniel Kulp wrote: On Thursday 07 December 2006 16:42, Joakim Erdfelt wrote: I would like to get maven-dependency-tree out of SNAPSHOT mode. I'm proposing making it 1.0-alpha-1. Found at https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tre e It is used by maven-project-info-reports-plugin (2.1-SNAPSHOT) and archiva (1.0-SNAPSHOT). Usual voting rules. +1/0/-1 72 hours (Vote counts collected at Sunday December 10th at 21:30:00 GMT) - Joakim -1 The normal set of issues: 1) pom.xml does not have the apache header 2) The rest of the files have the OLD apache header, not the new one required as of Nov 1. 3) No LICENSE of NOTICE file in the resulting jar (may need to wait for Jason's changes) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Daniel Kulp [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating JIRA
right, last time I brought this up the goal was to resolve all those for an actual 1.1 release.. I would like to see maybe an alpha-1 release in January perhaps followed up a beta or two once all the confirmed new features are in place (like profiles, etc). I think the decision had not be to actually break out something like alpha and beta releases into jira but for sanities sake perhaps we could reevaluate that. I know I went through about a month ago and poked through most of the issues making sure they were in the right components at least...but I think actually breaking down further into achievable shorter term goals would be a good thing. jesse On 12/9/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, If anything is thinking of doing a release of Continuum anytime soon can you please update Continuum's JIRA so that it's representative of what's going to be fixed for at least the next release like Kenney and I have done for Maven itself: http://jira.codehaus.org/browse/MNG I don't think you're doing to be fixing 163 issues for Continuum 1.1. Thanks, Jason. -- jesse mcconnell [EMAIL PROTECTED]
Re: A single groupId for Maven?
personally I like the nesting of a particular project under the groupId, like org.apache.maven.continuum... just unfortunate that maven was..well maven since org.apache.maven.maven would look rather goofy and its a bit late to change that :) what did you have in mind jason? pull things like continuum down a notch group wise and fill up the org.apache.maven group space with lots and lots of artifacts across all subprojects? jesse On 12/9/06, Eric Redmond [EMAIL PROTECTED] wrote: If projects like Wagon and SCM will always be managed by the Maven project, then it makes sense to put them under org.apache.maven. If they are planned to eventuall become stand-alone projects, used outside of maven, it kind of makes more sense to me to keep the groupIds distinct as they are - if something like SCM will eventually be like org.apache.scm anyway. Which leads me to ask: what is a group, exactly? Is it a (probably rotating) team of developers? Or a specific project? If the former, I'd say make them org.apache.maven. If the latter, keep them as is. Thanks; Eric On 12/9/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, Just looking at our proliferation of projects and that we have many groupIds and I'm wondering if we should be doing that and encouraging that? Should all our projects here have a groupId of org.apache.maven? Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eric Redmond http://codehaus.org/~eredmond -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] maven release process ( gpg / javadoc / site / source / remote-resources ) plugins.
+1 on all with those versions
On 12/10/06, Joakim Erdfelt [EMAIL PROTECTED] wrote:
Here is the breakdown, based on current voting.
Plugin Name | Version ID | Votes
maven-gpg-plugin | 1.0-alpha-1 | +8
maven-site-plugin | 2.0-beta-6 | +8
maven-remote-resources-plugin | 1.0-alpha-1 | +8
maven-source-plugin | 2.0.2 | +7
maven-javadoc-plugin | 2.2 | +7
- Joakim
Joakim Erdfelt wrote:
After a chat with Jason about the new release process / staging / etc...
I feel it is time to get a release out for the following plugins.
maven-gpg-plugin 1.0
maven-javadoc-plugin 2.2
maven-site-plugin 2.0
maven-source-plugin 2.0.2
maven-remote-resources-plugin 1.0
This will allow for the following ...
* release staging.
* gpg signing of all artifacts.
* ${artifactId}-${version}-sources.jar creation
* ${artifactId}-${version}-javadoc.jar creation
* Proper inclusion of the Apache LICENSE and NOTICE files.
I would like to call a vote on getting the 5 crucial plugins released in
a non-SNAPSHOT form.
Once these plugins are in place, the top level parent poms (maven-parent
and apache) can be updated to make these processes standard for all
releases.
To kick things off ...
+1 maven-gpg-plugin
+1 maven-javadoc-plugin
+1 maven-site-plugin
+1 maven-source-plugin
+1 maven-remote-resources-plugin
- Joakim Erdfelt
-
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]
--
jesse mcconnell
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: continuum-webapp models
yes, the output in the tables wanted certain summaries of data and project group and projects bits like name, group, etc.. so those were just model pojo's for ec:table to consume jesse On 12/13/06, Rahul Thakur [EMAIL PROTECTED] wrote: I haven't looked at this but is this purely as like a 'view data' for preparing views for the webapp? Cheers, Rahul Brett Porter wrote: anyone? On 01/12/2006, at 11:29 AM, Brett Porter wrote: I see a couple of models in continuum-webapp, which seem to be partially used. Does anyone know if session-models is used any more? What about view-models - only the summary parts still seem valid? - Brett -- jesse mcconnell [EMAIL PROTECTED]
Re: continuum-webapp models
no, brett' OP was asking if we could axe some of the unused stuff thats all On 12/13/06, Rahul Thakur [EMAIL PROTECTED] wrote: Hi Jesse, Just trying to understand - why do you suggest we drop the view data model (earlier email) if we could? Were you hinting that we use the domain entities directly in the view? I think we should keep separate model for the view data that only exposes that required stuff for view preparation. Rahul Jesse McConnell wrote: yes, the output in the tables wanted certain summaries of data and project group and projects bits like name, group, etc.. so those were just model pojo's for ec:table to consume jesse On 12/13/06, Rahul Thakur [EMAIL PROTECTED] wrote: I haven't looked at this but is this purely as like a 'view data' for preparing views for the webapp? Cheers, Rahul Brett Porter wrote: anyone? On 01/12/2006, at 11:29 AM, Brett Porter wrote: I see a couple of models in continuum-webapp, which seem to be partially used. Does anyone know if session-models is used any more? What about view-models - only the summary parts still seem valid? - Brett -- jesse mcconnell [EMAIL PROTECTED]
Re: svn commit: r487615 - in /maven/archiva/trunk/maven-meeper/src/site: fml/ fml/faq.fml fr/ fr/apt/ fr/apt/format.apt fr/apt/index.apt fr/fml/ fr/fml/faq.fml fr/xdoc/ fr/xdoc/xdoc.xml site.xml site_
+ /properties + body +section name=Bienvenue dans un fichier XDOC! + p +Ceci est du texte pour le fichier xdoc. + /p +/section + /body +/document + Added: maven/archiva/trunk/maven-meeper/src/site/site.xml URL: http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/ src/site/site.xml?view=autorev=487615 = = --- maven/archiva/trunk/maven-meeper/src/site/site.xml (added) +++ maven/archiva/trunk/maven-meeper/src/site/site.xml Fri Dec 15 10:39:19 2006 @@ -0,0 +1,24 @@ +?xml version=1.0 encoding=ISO-8859-1? +project name=Maven + bannerLeft +nameMaven/name +srchttp://maven.apache.org/images/apache-maven-project.png/ src +hrefhttp://maven.apache.org//href + /bannerLeft + bannerRight +srchttp://maven.apache.org/images/maven-small.gif/src + /bannerRight + body +links + item name=Apache href=http://www.apache.org/; / + item name=Maven 1.0 href=http://maven.apache.org// + item name=Maven 2 href=http://maven.apache.org/maven2// +/links + +menu name=Maven 2.0 + item name=APT Format href=format.html/ + item name=FAQ href=faq.html/ + item name=Xdoc Example href=xdoc.html/ +/menu + /body +/project Added: maven/archiva/trunk/maven-meeper/src/site/site_fr.xml URL: http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/ src/site/site_fr.xml?view=autorev=487615 = = --- maven/archiva/trunk/maven-meeper/src/site/site_fr.xml (added) +++ maven/archiva/trunk/maven-meeper/src/site/site_fr.xml Fri Dec 15 10:39:19 2006 @@ -0,0 +1,24 @@ +?xml version=1.0 encoding=ISO-8859-1? +project name=Maven + bannerLeft +nameMaven/name +srchttp://maven.apache.org/images/apache-maven-project.png/ src +hrefhttp://maven.apache.org//href + /bannerLeft + bannerRight +srchttp://maven.apache.org/images/maven-small.gif/src + /bannerRight + body +links + item name=Apache href=http://www.apache.org/; / + item name=Maven 1.0 href=http://maven.apache.org// + item name=Maven 2 href=http://maven.apache.org/maven2// +/links + +menu name=Maven 2.0 + item name=Format APT href=format.html/ + item name=FAQ href=faq.html/ + item name=Exemple Xdoc href=xdoc.html/ +/menu + /body +/project Added: maven/archiva/trunk/maven-meeper/src/site/xdoc/xdoc.xml URL: http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/ src/site/xdoc/xdoc.xml?view=autorev=487615 = = --- maven/archiva/trunk/maven-meeper/src/site/xdoc/xdoc.xml (added) +++ maven/archiva/trunk/maven-meeper/src/site/xdoc/xdoc.xml Fri Dec 15 10:39:19 2006 @@ -0,0 +1,15 @@ +?xml version=1.0? +document + properties +titleWelcome/title +author email=dev@maven.apache.orgThe Maven Team/author + /properties + body +section name=Welcome to an XDOC file! + p +This is some text for the xdoc file. + /p +/section + /body +/document + -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] release maven-ear-plugin (second try)
+1 On 12/16/06, Fabrizio Giustina [EMAIL PROTECTED] wrote: +1 fabrizio On 12/16/06, Stephane Nicoll [EMAIL PROTECTED] wrote: Hi, I'd like to release maven-ear-plugin 2.3 [1]. This release includes: * Support of classifier * Automatic generation of JBoss specific deployment descriptor (jboss-app.xml) * Support of exploded modules * File name mappings to avoid clashes * Support of HAR files * Bug fixes The snapshot is available on the staging site[2] The svn revision is 487859 Votes opened for 72h My +1 Cheers, Stéphane [1] http://jira.codehaus.org/browse/MEAR?report=com.atlassian.jira.plugin.system.project:roadmap-panel [2] http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/plugins/maven-ear-plugin/2.3-SNAPSHOT/ - 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] -- jesse mcconnell [EMAIL PROTECTED]
