Re: IT failures
+1 to Barrie's note. On Mon, Feb 10, 2014 at 9:55 AM, Barrie Treloar wrote: > On 10 February 2014 14:50, jieryn wrote: > > Don't mess with existing tests. It's always wrong to do it. You're > > lazy and stupid if you do it. > > Can you chill with the attitude. > Its not helpful, or appreciated. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Multi-project releases
And something like a CI server can make use of this capability as well. On 3/15/2013 2:20 AM, Robert Scholte wrote: At least the maven-help-plugin and probably the maven-site-plugin too. There's a small difference between the resolved pom for Maven(core) and the way paths are transformed for the maven-release-plugin and maven-site-plugin. here are some examples: https://jira.codehaus.org/browse/MSITE-669 https://jira.codehaus.org/browse/MSITE-672 https://jira.codehaus.org/browse/MSITE-657 Probably all URLs of distributionManagement are transformed for children, but that's not exposed with the help:effective-pom. Robert Op Thu, 14 Mar 2013 21:35:15 +0100 schreef Stephen Connolly : On Thursday, 14 March 2013, Robert Scholte wrote: Let's create a new shared component[1] for it: there are more plugins depending on this intelligence. What other plugins could be concerned with knowing which projects are roots for the release plugin? Or maybe you gave something else in mind? Looks to me there's no component for this kind of stuff yet. Robert [1] http://maven.apache.org/**shared/index.html<http://maven.apache.org/shared/index.html> Op Thu, 14 Mar 2013 10:32:26 +0100 schreef Stephen Connolly < stephen.alan.conno...@gmail.com>: No it makes more sense in the release plugin On 14 March 2013 09:16, Rahul Thakur wrote: And perhaps this capability can reside in Maven core? Just a thought On 3/12/2013 2:56 AM, Robert Scholte wrote: Hi, There are several MSITE/DOXIA and MRELEASE issues related to this subject. For the SCM-section and the site-section of the distributionManagement we need a more intelligent way to resolve this. Right now this logic is hidden inside the maven-release-plugin and maven-site-plugin, causing a different result when resolved as effective-pom, so IMO it is resolved at the wrong place. They way it should be resolved depends on the type of MavenProject: - aggregator (I'm not the parent of my modules) - multimodule-root (I'm the parent of modules) - module (I'm a module of my parent) - standalone (I'm not a module of my parent/I don't have a parent or modules) IMO modules should by default expand their parents path. Robert Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly < stephen.alan.connolly@gmail.com >: Hey one and all, So we all know how multiple projects with multiple release roots are a pain... Here's some experiments I've been playing with... Not yet brave enough to have it fire up release:prepare release:perform on each release root, nor fire up versions:set on the downstream projects with explicit dependencies, nor lather rinse repeat until there is nothing needing a release... But even the simple report should be useful, and if anyone has suggestions to help improve its recommendations towards getting confidence that the automated stuff could work... please give me pull requests. If this proves useful, I will probably roll it into the release plugin... but for now I'll keep it in a holding pattern on github (where it is not in a default plugin groupId and hence relocation is less of an issue if I do happen to make any releases into central) $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots from an aggregator pom should identify all the release roots and whether they might need a release -Stephen --** --**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org< dev-unsubscr...@maven.apache.org> For additional commands, e-mail: dev-h...@maven.apache.org --** --**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org< dev-unsubscr...@maven.apache.org> For additional commands, e-mail: dev-h...@maven.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org . - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Multi-project releases
And perhaps this capability can reside in Maven core? Just a thought On 3/12/2013 2:56 AM, Robert Scholte wrote: Hi, There are several MSITE/DOXIA and MRELEASE issues related to this subject. For the SCM-section and the site-section of the distributionManagement we need a more intelligent way to resolve this. Right now this logic is hidden inside the maven-release-plugin and maven-site-plugin, causing a different result when resolved as effective-pom, so IMO it is resolved at the wrong place. They way it should be resolved depends on the type of MavenProject: - aggregator (I'm not the parent of my modules) - multimodule-root (I'm the parent of modules) - module (I'm a module of my parent) - standalone (I'm not a module of my parent/I don't have a parent or modules) IMO modules should by default expand their parents path. Robert Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly : Hey one and all, So we all know how multiple projects with multiple release roots are a pain... Here's some experiments I've been playing with... Not yet brave enough to have it fire up release:prepare release:perform on each release root, nor fire up versions:set on the downstream projects with explicit dependencies, nor lather rinse repeat until there is nothing needing a release... But even the simple report should be useful, and if anyone has suggestions to help improve its recommendations towards getting confidence that the automated stuff could work... please give me pull requests. If this proves useful, I will probably roll it into the release plugin... but for now I'll keep it in a holding pattern on github (where it is not in a default plugin groupId and hence relocation is less of an issue if I do happen to make any releases into central) $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots from an aggregator pom should identify all the release roots and whether they might need a release -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Desupport Maven 1
+1 On 2/28/2013 1:15 AM, Stéphane Nicoll wrote: +1 Sent from my iPhone On 27 Feb 2013, at 19:34, Benson Margulies wrote: I think it's long overtime for us to officially disclaim support for Maven 1. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: New PMC Member
Congratulations, Paul! Rahul On Sat, May 15, 2010 at 3:04 AM, Brian Fox wrote: > The Maven PMC recently voted to invite Paul Gier to join us as a > member of the PMC Committee. He accepted and is now officially part of > the Maven PMC. Congratulations Paul! > > If you'd like to read more about what his exactly means, take a look > at http://www.apache.org/foundation/how-it-works.html > > --Brian Fox > Maven PMC Chair. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: [VOTE] Commit access for Mark Struberg
+1 Rahul On Thu, Jul 30, 2009 at 5:04 PM, Brett Porter wrote: > Hi, > > Mark has been contributing regularly to Maven SCM for quite some time (in > particular the git support recently, and I think has been wanting to help > with improving the API and release mechanism for git), as well as being more > broadly active. > > I think he'd be a great addition to the team. > > He is already an Apache committer (on two incubating projects). > > +1 from me. > > Cheers, > Brett > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Meetup @ Sonatype on March 19th & 20th
Hi Jason, Any chance if these session recordings will be available to the wider community after EclipseCon, ApacheCon? Thanks, Rahul On 12/03/2009 10:34 a.m., Jason van Zyl wrote: Hi, For those interested in knowing what Sonatype is working on in the Maven community, we're having a Maven Meetup the week before EclipseCon in Mountain View. It's a full day of presentations on Maven and related technologies like m2eclipse, Nexus, Tycho, Hudson, NMaven, NAR, FlexMojos and more. That will be followed up by a full day hackathon. You can see the full description here: http://www.sonatype.com/people/2009/03/sonatype-maven-meetup-on-march-19th-20th/ And you can signup to attend here: https://docs.sonatype.org/display/COMM/Maven+Meetup+on+March+19th+and+20th+at+Sonatype We are syncing up with the Hippo folks who are putting on the Maven Meetup in Amsterdam (unfortunately the conference organizers didn't notice that EclipseCon and ApacheCon are in the same week) as none of the Sonatype folks can attend ApacheCon. We are planning to record all the sessions on the 19th and so they should be available for everyone at ApacheCon. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Off Topic] Re: Code provenance checks for Plexus components
IIRC, some of the sources are under ASL 2.0. I think I have seen some source headers with MIT and some with Common Public License. Rahul On 28/02/2009 4:18 p.m., Abel Muiño wrote: Arnaud HERITIER wrote: No it's not the case.I often find Apache processes heavy,, but if in eclipse you have to validate all dependencies I better understand why its quality is lower day after day. All teams are probably checking their dependencies instead of writting tests. I think there is a misconception about the Eclipse Process and how heavy it is. We have checked a sheer number of dependencies and, so far, the only problem is with Plexus. The ip-team takes care of everything for us, so it is just a matter of getting in the mental state to file a bug report stating what you will use. However, the case of the embedder is a very speciall one, given the number of dependencies required from so many different sources, and the lack of information about its licensing terms or process in a few of them. The intent of the Eclipse Process is that commercial tools can be built on top of eclipse projects and, given that the Plexus license page [1] states that "No project license is defined for this project.", I can understand that the legal team is worried. [1] http://plexus.codehaus.org/license.html On Fri, Feb 27, 2009 at 8:34 PM, Abel Muiño wrote: Ok, sorry for the noise then... I thoght that Apache would somehow review the code from third parties before distributing it (that's the Eclipse way). Brian E Fox wrote: Plexus is a codehaus component, so Apache would most likely not have these checks. -Original Message- From: Abel Muiño [mailto:amu...@gmail.com] Sent: Friday, February 27, 2009 1:18 PM To: dev@maven.apache.org Subject: Code provenance checks for Plexus components The Eclipse legal team is having a hard time trying to confirm code provenance for the plexus components required by the 3.0 maven embedder. I suppose that the Apache Foundation has already done similar provenance checks before distributing the components... so can you please help us with the Eclipse review? Specifically, the legal team has asked: ··· For example, it would be helpful to know whether Plexus project members and contributors are asked to acknowledge anything regarding their contribution in an e-mail (e.g. I wrote the code, it's mine, and I'm contributing it to Plexus for distribution under the Apache 1.1 or Apache 2.0 license). ··· Does such thing (or anything similar) exist? Does Apache keep some records regarding the 3rd party checks it performs before a release? Thanks! - http://www.linkedin.com/in/amuino Abel Muiño Vizcaino - http://ramblingabout.wordpress.com http://ramblingabout.wordpress.com -- View this message in context: http://www.nabble.com/Code-provenance-checks-for-Plexus-components-tp22251436p22251436.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - http://www.linkedin.com/in/amuino Abel Muiño Vizcaino - http://ramblingabout.wordpress.com http://ramblingabout.wordpress.com -- View this message in context: http://www.nabble.com/Code-provenance-checks-for-Plexus-components-tp22251436p22252875.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 2.0.10-RC4
OTOH, there is a 'Fix Version' property in JIRA that you can use to assign a release/build/version id. Rahul On Fri, Aug 1, 2008 at 9:28 AM, Paul Benedict <[EMAIL PROTECTED]> wrote: > Is there anywhere in JIRA we can tag some issues as being fixed in RC1, RC2, > etc.? I liked how Bugzilla had flags to mark items. Anything like that in > JIRA? > > Paul > > On Thu, Jul 31, 2008 at 4:16 PM, Brett Porter <[EMAIL PROTECTED]> wrote: > >> Would this be a good one to push to users@, particularly highlighting the >> need to test projects with creative uses of interpolation and various >> deployment setups? >> >> Cheers, >> Brett > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit privs for Shane Isbell
+1 Rahul Jason van Zyl wrote: Hi, Shane has been been working on NMaven for a couple years now, he's worked on the new maven-toolchain, has recently done a huge amount of work on cleaning up the project builder in the sandbox, and has some PGP tools that he would like to contribute. So overall given the time he's been around in the community and the the massive amount of work he's done lately I propose that we give him commit privs. Primarily because I don't want to merge his branch of 2.1 :-) +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
+1 Rahul Jason van Zyl wrote: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 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]
Re: Go Hudson!
[snipped] Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa [snipped] That's Akira Kurosawa (not Kirosawa)! :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Eclipse plugin version 2.5.1
duh me! Please ignore; sorry about the noise. It was the root pom. Rahul Thakur wrote: Is there a change in the recent release that is using 'build' folder for output by default? I generated Eclipse projects for Continuum and all projects have output folder set to 'build' in absence of any specified folders. The online plugin docs suggest otherwise; bug? Rahul Brian E. Fox wrote: This only works on single module builds, the prerequisite field is not inherited. -Original Message- From: Jerome Lacoste [mailto:[EMAIL PROTECTED] Sent: Thursday, April 03, 2008 4:33 AM To: Maven Developers List Subject: Re: [VOTE] Release Maven Eclipse plugin version 2.5.1 On Wed, Apr 2, 2008 at 11:13 AM, Arnaud HERITIER<[EMAIL PROTECTED]> wrote: Hi Jerome, As you noticed, this plugin requires to be build with maven>= 2.0.8 because of some tests with encodings. I'll add an enforcer rule as Benjamin proposed. I had added a patch to the issue hat uses the inbbuild POM requireMavenVersion instead of using the enforcer plugin. That worked for me. Cheers, Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Eclipse plugin version 2.5.1
Is there a change in the recent release that is using 'build' folder for output by default? I generated Eclipse projects for Continuum and all projects have output folder set to 'build' in absence of any specified folders. The online plugin docs suggest otherwise; bug? Rahul Brian E. Fox wrote: This only works on single module builds, the prerequisite field is not inherited. -Original Message- From: Jerome Lacoste [mailto:[EMAIL PROTECTED] Sent: Thursday, April 03, 2008 4:33 AM To: Maven Developers List Subject: Re: [VOTE] Release Maven Eclipse plugin version 2.5.1 On Wed, Apr 2, 2008 at 11:13 AM, Arnaud HERITIER<[EMAIL PROTECTED]> wrote: Hi Jerome, As you noticed, this plugin requires to be build with maven>= 2.0.8 because of some tests with encodings. I'll add an enforcer rule as Benjamin proposed. I had added a patch to the issue hat uses the inbbuild POM requireMavenVersion instead of using the enforcer plugin. That worked for me. Cheers, Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANSI color logging in Maven
Not sure about Eric, but Andrew Williams did some work under Plexus sandbox. Rahul Brian E. Fox wrote: I thought Eric had something hacked up at one point? -Original Message- From: James William Dumay [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2008 8:22 PM To: Maven Developers List Subject: Re: ANSI color logging in Maven Rahul, Something like this library might help you in your quest... http://sourceforge.net/projects/javacurses/ James On Tue, 2008-04-08 at 10:40 +1200, Rahul Thakur wrote: Hello, I have opened an enhancement request for ANSI color logging for Maven here. http://jira.codehaus.org/browse/MNG-3507 I believe it would be a neat usability enhancement to Maven and make it much easier to skim through logging output on the console. Thoughts? Cheers, Rahul - 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]
ANSI color logging in Maven
Hello, I have opened an enhancement request for ANSI color logging for Maven here. http://jira.codehaus.org/browse/MNG-3507 I believe it would be a neat usability enhancement to Maven and make it much easier to skim through logging output on the console. Thoughts? Cheers, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Maven 2.0.9
+1, works fine for me.
Rahul
Brian E. Fox wrote:
Time to vote on the final Maven 2.0.9 Release. We went through 8 Release
Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
that time. Note that there were no source changes between RC8 and this
final build.
Release is staged at:
http://people.apache.org/~brianf/stage-2.0.9
Binaries are here:
http://people.apache.org/~brianf/stage-2.0.9/org/apache/maven/apache-mav
en/2.0.9/
List of issues fixed:
Release Notes - Maven 2 - Version 2.0.9
** Bug
* [MNG-1412] - dependency sorting in classpath
* [MNG-1914] - Wrong url in error message when using a mirror
* [MNG-2123] - NullPointerException when a dependency uses version
range and another uses an actual version incompatible with that range
* [MNG-2145] - Plugins' dependencies are not always checked
* [MNG-2178] - incorrect M2_HOME guess in mvn.bat
* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
profiles section is missing or empty
* [MNG-2339] - ${project.*} are interpreted in the wrong place
* [MNG-2744] - checksum comparison should be case-insensitive
* [MNG-2809] - Can't activate a profile by checking for the presence
of a file in ${user.home}
* [MNG-2848] - Environment variables in profile activation not
working
* [MNG-2861] - NullPointerException in DefaultArtifactCollector for
relocated resolvedArtifacts with different version ranges and available
versions.
* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if
there's no mojo in pom.xml
* [MNG-2928] - Null pointer exeception when introducing version
range [major.minor.build-SNAPSHOT,)
* [MNG-2972] - Ignores version of plugin dependency specified in my
pom
* [MNG-3086] - NullPointerException in
ResolutionNode.getTrail(ResolutionNode.java:136)
* [MNG-3099] - Profiles ignored when working with non-projects (such
as archetype:create)
* [MNG-3111] - Classpath order incorrect
* [MNG-3156] - NullPointerException with mvn dependency:sources
* [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
* [MNG-3259] - Regression: Maven drops dependencies in multi-module
build
* [MNG-3286] - execution.inherited field is ignored
* [MNG-3288] - Invalid systemPath allows build to continue--failing
in later phase.
* [MNG-3296] - mvn.bat looses error code on windows NT type
platforms
* [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set
* [MNG-3316] - Barfs at attribues named .*encoding
* [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP
with Novell login
* [MNG-3355] - CLONE -${pom.build.sourceDirectory} and
${pom.build.testSourceDirectory} no longer recognized
* [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat
* [MNG-3394] - Plugin versions inherited via
cannot be overriden by. section of sub modules
* [MNG-3396] - Managed versions dont affect over constrained ranges
* [MNG-3400] - MavenProject is not extensible
* [MNG-3405] - "Checking for updates from repository" logging should
not display if WagonManager is offline
* [MNG-3410] - Managed versions in plugins are not considered when
using them
* [MNG-3415] - Transfer errors cause junk metadata in the local repo
* [MNG-3426] - regression : in plugin configuration
doesn't override plugin classpath
* [MNG-3430] - Toolchain doesn't match Toolchain extensions
* [MNG-3431] - Pom Extensions not supported for Toolchains
* [MNG-3439] - incorrect child dependency selected when parent is
not selected
* [MNG-3441] - Maven should always retrieve metadata to be updated
from the deployment repository
* [MNG-3460] - org.apache.maven.profiles.DefaultProfileManagerTest
fails if you use a different local repo
* [MNG-3464] - maven-toolchains missing from final binary.. need to
update the assembly
* [MNG-3473] - site generation with 2.0.9 and plugin:report (2.4
ONLY) is broken
* [MNG-3484] - INT_MAVEN_OPTS are not quoted in mvnDebug which
causes issues on some shells
* [MNG-3485] - unable to override wagons that are bundled with a
different version via extensions
* [MNG-3494] - local pom dependencies should get injected before
inherited dependencies
* [MNG-3495] - NPE at
org.apache.maven.wagon.repository.Repository.hashCode(Repository.java:24
1)
** Improvement
* [MNG-428] - Japanese message resource
* [MNG-2881] - Improve logging when downloading snapshots in offline
mode
* [MNG-3279] - Support Exception Chaining for MojoFailureException
* [MNG-3318] - ActiveProjectArtifact should have appropriate equals
and hashCode methods
* [MNG-3331] - Normalize paths to sub modules
* [MNG-3388] - DefaultPluginManager needs to catch LinkageError
* [MNG-3395] - Default core plugin versions in the superpom.
* [MNG-3442] - Ad
Re: how to start / stop the tomcat 6 server with maven2
Hi, Have a look at Cargo Maven 2 Plugin. (http://cargo.codehaus.org) I think there is also a tomcat plugin under Mojo project. (http://mojo.codehaus.org) Please start a new thread/post if you are not replying to an existing one instead, as it can be inconvenient to the users who use conversation view in a mail client or users who search through mail archives looking for answers. Thanks, Rahul [EMAIL PROTECTED] wrote: Hi in my project we r using tomcat 6.0 and maven2 How to start / stop the tomcat 6 server with maven2 Can any help me / send sample code / guide me Thanks& Regards, Sridhar Thota, Accenture - India | O: +91 22 40444170 | Ext: 4170 | C: +91 9930245689 | Aim/gTalk: mails4sri | Mial/YIm/Msn: sridhar.thota -Original Message- From: PashaOvechkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 1:57 PM To: dev@maven.apache.org Subject: RE: How to build properties JAR Hmmm... By default? I create src/main/resources directory, and run my pom... Don't see any properties jar :| Brian E Fox wrote: Put them in src/main/resources and it should happen by default. -Original Message- From: PashaOvechkin [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2008 11:53 AM To: dev@maven.apache.org Subject: How to build properties JAR I need with Maven command get jar with properties files(only with properties files). What i need add in my pom.xml? (for example in the same directory with pom.xml I have aaa.properties and bbb.properties, and need jar with both files) Tanks!!! -- View this message in context: http://www.nabble.com/How-to-build-properties-JAR-tp16254904s177p1625490 4.html Sent from the Maven Developers mailing list archive at Nabble.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XBean and DI?
Hi Jason, Is this hosted somewhere where we can take a look or start poking around? Cheers, Rahul Jason van Zyl wrote: On 28-Feb-08, at 3:00 PM, Barrie Treloar wrote: Jason, do you want to talk some more about XBean, DI, & Maven/Plexus etc? XBean Reflect (XBR) is really something more akin to Guice. XBR is more complete then what I have in Plexus and I honestly only ever cared about private field injection and Plexus only does constructor and setter injection now. XBR does private field, constructor, bean factory, and setter injections. Dain and I chatted and decided to come up with an interface for DI that XBR would provide and that Plexus could consume. Dain has done the XBR side and is now going to remove Plexus' DI in favor of XBR. XBR is currently used in OpenEJB and David Jencks might be interested in it for Geronimo. So that would be the first step of collapsing out the DI code in Plexus and using XBR as a library. I have also been talking with the Pico folks and if we could then abstract some container features I would be happy to chop out another huge chunk of Plexus and use Pico. So I'm hoping that we can arrive at the interface for DI which Pico and Plexus can use, and then take the bottom out of Plexus and use Pico in there. Ultimately the features I have in Plexus that I like are specifically for plugin systems like Maven. I have mechanisms for component configuration, configuration sources which can configure multiple components (like an application specific configuration being mapped on to components, this is what is done in Nexus), dynamic metadata translation (maven plugins are plexus components which are flipped on the fly), dynamic component discovery (maven plugins don't exist anywhere in the system until they are downloaded and wired up in the container), and runtime nature of a component system. Really this is what I am interested in and if Dain, Paul, Mauro, Peter want to do the DI and base container stuff that's great. We have all made containers and while it's very interesting we all go to bed at 10pm now, have lives (well some of us) and if we want any traction we know we have to work together. Dain, Paul and myself have been trying to hash this out for 4 years while things like Spring just took over, and things like Juice popped up. We're trying to take our personalities out of the equation (and that is very, very, very hard as we're all territorial which is good and bad) and make a better system. The other interesting thing is that Dain sees JAXB as being an almost complete DI system itself. So if we create this interface and we can get Kohsuke to mess around with JAXB then maybe we can throw all our stuff away and let JAXB do the DI. That's where we're headed and it finally looks like we're making some headway. Dain will probably be done the first pass next week sometime and then we'll spend a week finding all the problems by running the Maven ITs. None of us are interested in using Spring but we're interested in running Spring applications which there are chunks of code lying around. And none of us are really interested in using OSGi but definitely want to interoperate (I actually had a good chat with Jeff McAffer and we actually talked about what would need to be done to run Maven on OSGi). We all like containers and want to continue working on them and we realize we can work on more interesting problems if we work together. This may seem perfectly obviously but it's been nearly impossible to get this point. Dain, Paul, and myself are very similar and in the past many of the conversation would go something like "Hmm, that's nice. My container can do this, my container can do that ... yada yada yada." Meanwhile many other systems have cropped up and served people better. I'm not a big fan of Spring's internals or architecture but absolutely no one can argue with their dedication to users, good documentation, helpful community and we realize we've done a disservice to people using our stuff because we can't cooperate. The merger of XBR into Plexus will be the first step away from this pattern and it's almost done. I've had a brief look at http://geronimo.apache.org/xbean/index.html but some of the pages are thin and the diagrams are coming up with exceptions. - 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] Fo
Re: Plexus classloader
You could also use Eclipse's ASTParser to scan sources for annotations. Rahul Jason van Zyl wrote: On 25-Feb-08, at 2:21 AM, Bengali Bengali wrote: I need to find annotated classes and generate an XML file. Since i haven't found any good library to scan source files for annotations. QDox is awesome. It's what we use actually. I decided to compile classes -> then run my maven plugin to find annotations. I have been able to do it instantiating my own classloader (adding it target/classes directory) and running my class scanner to detect annotations. It works now but i have to perform some reflection to instantiate my scanner in its own classloader. I thought of using my class scanner directly in my maven plugin and run the plugin in a URLClassLoader that has already the classes/target url in it. Hope i have been clear enough. Thanks Luc On Sat, Feb 23, 2008 at 1:59 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: It has the code for populating a classloader, and anything in Maven uses plexus. If you're writing a Maven plugin it uses plexus. What exactly are you trying to do aside from populating a classloader with the classes and dependencies of the current project? On 22-Feb-08, at 1:55 PM, Bengali Bengali wrote: Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- the course of true love never did run smooth ... -- 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]
Re: trunk & shading
Thanks for the rationale, Jason. My intent was to understand from a classloading and modularity perspective. Cheers, Rahul Jason van Zyl wrote: On 26-Feb-08, at 6:29 PM, Rahul Thakur wrote: On a related note, I have always wondered why Maven was not using OSGi underneath? Because it wasn't very mature 3 years ago, and aside from the classloader mechanism which is really quite amazing there isn't much in the component model that's overly impressive. What has existed in Avalon is really a better component model that's in OSGi, and general dependency injection is generally pretty poor in OSGi. What is in XBean, Pico, Spring, Yan, and Juice have better dependency injection capabilities. The modularity aspects of OSGi are good, the rest of it I don't really care for and will go the path of cooperating with Dain and Paul on Pico and XBean. This evening Dain Sundstrom, David Blevins, David Jencks and Kohsuke Kawaguchi talked about JAXB replacing all these mechanisms. JAXB is so close to doing DI for everything. Dain is currently working on replacing the DI in Plexus with XBean reflect and then we'll work with Paul to make this work with Pico. I've talked with Jeff McAffer to about OSGi and we've already identified many things OSGi can't do insofar as running Maven. But in the coming months many things are going to fall out with respect to containers. Rahul Paul Benedict wrote: Would shading be eliminated if Maven 2.1 integrated OSGi so that component and plugin dependencies can be totally isolated from each other (i.e., privatized)? Paul On Tue, Feb 26, 2008 at 7:59 PM, Jason van Zyl<[EMAIL PROTECTED]> wrote: On 26-Feb-08, at 5:40 PM, Brett Porter wrote: On 27/02/2008, at 11:32 AM, Jason van Zyl wrote: The reason for this is that commons-logging in the root classloader makes plugins unhappy (and the error reporting seems to be swallowed now). What about using slf4j and it's commons-logging replacement? this didn't give me any luck unfortunately. I'm not entirely comfortable tossing commons-logging into the root classloader at this stage without tying it into the plexus logging properly, so I think the pre-shaded webdav library is the way to go at this point (it's essentially the same thing). No the replacement for commons logging, so there is no commons logging jar in the root classloader. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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 -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: trunk & shading
On a related note, I have always wondered why Maven was not using OSGi underneath? Rahul Paul Benedict wrote: Would shading be eliminated if Maven 2.1 integrated OSGi so that component and plugin dependencies can be totally isolated from each other (i.e., privatized)? Paul On Tue, Feb 26, 2008 at 7:59 PM, Jason van Zyl<[EMAIL PROTECTED]> wrote: On 26-Feb-08, at 5:40 PM, Brett Porter wrote: On 27/02/2008, at 11:32 AM, Jason van Zyl wrote: The reason for this is that commons-logging in the root classloader makes plugins unhappy (and the error reporting seems to be swallowed now). What about using slf4j and it's commons-logging replacement? this didn't give me any luck unfortunately. I'm not entirely comfortable tossing commons-logging into the root classloader at this stage without tying it into the plexus logging properly, so I think the pre-shaded webdav library is the way to go at this point (it's essentially the same thing). No the replacement for commons logging, so there is no commons logging jar in the root classloader. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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 -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Benjamin Bentmann as Maven committer
+1 Rahul Lukas Theussl wrote: I'd like to propose giving commit access to Benjamin. During the last few months, he has provided patches in so many areas of Maven that I can't list them all here (various plugins, surefire, doxia,...), including documentation and translations, and he has not been afraid to actively discuss things on the dev list. I think he would make a great addition to our team. +1 -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't run Maven 2.1 Snapshot
Thanks Carlos, that was it! I was setting M2_HOME from command prompt after building M2 trunk but it seems that PATH was still using the old M2_HOME value Cheers, Rahul Carlos Sanchez wrote: I saw that problem before and IIRC it was a problem wiht my M2_HOME and PATH, both were not in sync pointing to the same 2.1-snapshot On Fri, Feb 15, 2008 at 10:26 AM, Rahul Thakur <[EMAIL PROTECTED]> wrote: I get the error below when I attempt to build and run a Maven 2.1 SNAPHOT on win xp. Rahul E:\maven-components>mvn -X package Exception in thread "main" java.lang.NoClassDefFoundError: org/codehaus/classworlds/Launcher Caused by: java.lang.ClassNotFoundException: org.codehaus.classworlds.Launcher at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) - 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]
Can't run Maven 2.1 Snapshot
I get the error below when I attempt to build and run a Maven 2.1 SNAPHOT on win xp. Rahul E:\maven-components>mvn -X package Exception in thread "main" java.lang.NoClassDefFoundError: org/codehaus/classworlds/Launcher Caused by: java.lang.ClassNotFoundException: org.codehaus.classworlds.Launcher at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please comment: 2.1 Lifecycle Features on MAVEN Confluence space
Hi John, That looks very interesting! BTW, what is 'Just-in-time lifecycle discovery and configuration'? Rahul 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discussion] Continuum 2.0 Roadmap
Jesse McConnell wrote: 1-2)I would like to bring Guice to the mix. I think it is worth investigating for Continuum 2.0 - WDYT? I don't think. I don't see the interest to look at it for Continuum. We already use Plexus that works fine, and if we decide to move to something else, it should be for the interest of the project and features we don't have in Continuum. But maybe you have some arguments about Guice. From what I have seen and used of Guice, its a very tight implementation that leverages Java 5 Generics and Annotations. Have a look here for some more: http://code.google.com/p/google-guice/wiki/SpringComparison my only comment here is that last I heard plexus was merging with Pico I think and going into apache as Apache Composer...so while plexus does everything continuum needs now, there is like a container update/upgrade somewhere in our future :) jesse
Re: Some continuum-jpa branch updates
A Query object that wraps up criteria and is built programmatically affords us the ability to keep Store APIs lean and stable. That is the motivation behind building up queries programatically. IMHO, the current ContinuumStore is a bunch of methods that don't even vary that much underneath. I think the same can be easily achieved by using Query. I am not sure if StringBuilder will be more performant than StringBuffer when you are concatenating only a few Strings. I think what is more important is a goal of a lean, test'able and clean API. I can't really comment on named queries (probably need to toy around with them a bit), and not sure how the implementation would end up making use of named queries, but if anyone else has any opinions, I am keen to understand. Cheers, Rahul Emmanuel Venisse wrote: As Christian said, named queries are pre-compiled to SQL. With dynamic queries, perf can be not good because for each execution, the JPQL request is recompile to SQL, so parsing, creation of the JPQL tree then SQL generation, and with your solution, you concatenate lot of String. It isn't important for one request but with lot of request, you use more time and cpu, for string concatenation, it is better to use StringBuilder that is more performant than String addition or StringBuffer. An other argument for named queries is that with dynamic queries, if they aren't written correctly (it isn't the case for your code ;) ), it is easy to introduce some malicious SQL code with parameters my two cents. Emmanuel On Jan 18, 2008 9:57 PM, Christian Edward Gruber<[EMAIL PROTECTED]> wrote: You can get some benefit from named queries in terms of query pre- compilation and caching on the underlying database. However, most database flavors and hibernate providers turn criteria queries into named queries (parameterized SQL) which is then cached, so, on the surface I suspect the performance characteristics will be similar. Christian. On 18-Jan-08, at 14:35 , Rahul Thakur wrote: Thanks Emmanuel! Responses inlined... Emmanuel Venisse wrote: Hi Rahul, After few days to look at JPA, I'm sure now it would be good to use it instead of the actual JDO/JPOX (I know JPOX 1.2 support JPA). The code is very easy to write and to read with JPA. About your continuum-jpa branch, I have few remarks: - I don't think it's good to use directly some OpenJPA APIs. If possible, I'd prefer to use only standard JPA APIs so we'll can choose later the implementation we want to use (OpenJPA, TopLink, JPOX...) Agree. The only place where OpenJPA APIs are being used directly currently are the unit tests. - why do you use some Spring code? Experimental. Spring has a good transaction management framework out of the box. - we don't need to store the model encoding (CommonUpdatableModelEntity class) Sure. Easily fix'able. :-) - can you explain dateCreated/dateUpdated fields? How are they managed? These are for audit puposes, and can be used as range search query criteria for fetching entities. These were an extension I thought will be good. 'dateCreated' gets set when an entity is first inserted into the underlying store, subsequent updates update the 'dateUpdated'. - all the model is fectched eagerly and it isn't acceptable for performance Yes, the model does needs review and tweaks to annotations where we know we don't need to fetch 'eagerly'. - I'm not sure your Query "pattern" is good. I'd prefer to use named queries but maybe you have a reason I think using a Query like we have on the JPA branch nicely provides for a flexible construction of queries (i.e, only the criteria passed in contributes to the query). I am not sure if such is available with named queries; but I am interested to know why named queries might be better. Cheers, Rahul That's all for the moment. Emmanuel On Jan 16, 2008 11:30 PM, Rahul Thakur <[EMAIL PROTECTED]> wrote: Just wondering if anyone else got to the changes? Emmanuel Venisse wrote: I don't have the time to look at it these days but I'll do it asap (maybe in few weeks :( ) Emmanuel Rahul Thakur a écrit : Hi All, Scribbling some quick notes on some of the toying around I have been doing with OpenJPA, Generics etc on the continuum-jpa branch[1]: 1) Use JPA for persistence Motivation behind this has been to investigate how this compares to JPOX/JDO for managing the model - both in terms on performance and ease of use (Store APIs). Continuum model classes are annotated with JPA annotations on the branch. However, this needs a review as there are some elements (for example 'configuration' typed as Map) that I am not sure yet how to persist y
Re: Continuum update
Emmanuel Venisse wrote: Hi, I'll probably create a new branch for 1.x dev and will reserve the trunk for 2.x dev. I think I'll do it this week or the next (if you're agree, of course :) ) +1. I'll try to send at the same time my ideas for 2.x so we'll can discuss about them. +1. I think it might be an idea to outline the design ideas on the wiki, and have discussions on here and keep the design doc in sync. Cheers, Rahul Emmanuel
Re: [vote] release maven-dependency-plugin 2.0
+1 Rahul Brian E. Fox wrote: It's been a long time since the last release and we have lots of improvements/fixes: Release Notes - Maven 2.x Dependency Plugin - Version 2.0 ** Bug * [MDEP-59] - dependency:unpack can't extract rar archives * [MDEP-74] - dependencies in test scope are not handled properly by analyze * [MDEP-75] - non-portable classpath separator in build-classpath output * [MDEP-80] - Usage page of the docs use an overWrite property, but none exists in the (auto-generated) goal reference docs * [MDEP-81] - analyzer can't handle non-pom projects that don't produce a /target folder * [MDEP-83] - Typo in "How to prepare your dependencies before updating to Maven 2.0.6" * [MDEP-91] - org.codehaus.mojo:dependency-maven-plugin takes precedence over org.apache.maven.plugins:maven-dependency-plugin * [MDEP-93] - Tests can fail with OOME * [MDEP-95] - can't build unit tests with jdk1.4 rev 545703 * [MDEP-97] - dependency:tree not consistent with maven core's dependency tree * [MDEP-113] - Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-SNAPSHOT * [MDEP-120] - build-classpath is unable to build a classpath with runtime or test dependencies ** Improvement * [MDEP-89] - change separators in build-classpath * [MDEP-96] - Allow includes and excludes to be used simultaneously in the same filter * [MDEP-99] - Unpack SWC files * [MDEP-100] - Merge dependency:tree branch for new features * [MDEP-101] - Add dependency:list alias for dependency:resolve * [MDEP-104] - Add Analyze HTML Report * [MDEP-111] - Provide output on file as in other goals * [MDEP-119] - build-classpath should create destination directory for the classpath file * [MDEP-125] - Build-classpath should store the classpath in a Filter * [MDEP-129] - allow substitution of the absolute local repo path with a property * [MDEP-130] - allow the classpath file to be attached * [MDEP-131] - Complete i18n support for new analyze-report * [MDEP-132] - Add german translation for analyze-report mojo * [MDEP-133] - Add dedicated resource bundle for locale "en" ** New Feature * [MDEP-47] - Ability to have an includes/excludes feature on the dependency:unpack goal. * [MDEP-70] - add new mojo to perform analysis of dependencies and fail the build if certain conditions aren't met * [MDEP-71] - add report to display contents of dependency-analyzer * [MDEP-94] - Add dependency:tree goal * [MDEP-116] - [dependency :copy-dependencies ] Add parameter to allow extracting POMs Staged at: http://people.apache.org/~brianf/staging-repository Vote is open for 72hrs. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some continuum-jpa branch updates
Thanks Emmanuel! Responses inlined...
Emmanuel Venisse wrote:
Hi Rahul,
After few days to look at JPA, I'm sure now it would be good to use it
instead of the actual JDO/JPOX (I know JPOX 1.2 support JPA).
The code is very easy to write and to read with JPA.
About your continuum-jpa branch, I have few remarks:
- I don't think it's good to use directly some OpenJPA APIs. If possible,
I'd prefer to use only standard JPA APIs so we'll can choose later the
implementation we want to use (OpenJPA, TopLink, JPOX...)
Agree. The only place where OpenJPA APIs are being used directly
currently are the unit tests.
- why do you use some Spring code?
Experimental. Spring has a good transaction management framework out of
the box.
- we don't need to store the model encoding (CommonUpdatableModelEntity
class)
Sure. Easily fix'able. :-)
- can you explain dateCreated/dateUpdated fields? How are they managed?
These are for audit puposes, and can be used as range search query
criteria for fetching entities. These were an extension I thought will
be good. 'dateCreated' gets set when an entity is first inserted into
the underlying store, subsequent updates update the 'dateUpdated'.
- all the model is fectched eagerly and it isn't acceptable for performance
Yes, the model does needs review and tweaks to annotations where we know
we don't need to fetch 'eagerly'.
- I'm not sure your Query "pattern" is good. I'd prefer to use named queries
but maybe you have a reason
I think using a Query like we have on the JPA branch nicely provides for
a flexible construction of queries (i.e, only the criteria passed in
contributes to the query). I am not sure if such is available with named
queries; but I am interested to know why named queries might be better.
Cheers,
Rahul
That's all for the moment.
Emmanuel
On Jan 16, 2008 11:30 PM, Rahul Thakur <[EMAIL PROTECTED]> wrote:
Just wondering if anyone else got to the changes?
Emmanuel Venisse wrote:
I don't have the time to look at it these days but I'll do it asap
(maybe in few weeks :( )
Emmanuel
Rahul Thakur a écrit :
Hi All,
Scribbling some quick notes on some of the toying around I have been
doing with OpenJPA, Generics etc on the continuum-jpa branch[1]:
1) Use JPA for persistence
Motivation behind this has been to investigate how this compares to
JPOX/JDO for managing the model - both in terms on performance and
ease of use (Store APIs). Continuum model classes are annotated with
JPA annotations on the branch. However, this needs a review as there
are some elements (for example 'configuration' typed as Map) that I am
not sure yet how to persist yet. The provider used is OpenJPA [2].
2) Refactorings to Store interface
Main motivation has been to keep the core Store interface lean and
mean (read extensible). The Store interface[3] now has 4 methods:
lookup()
save()
delete()
query()
The lookup(), save() and delete() act on single model Entity, while
query() will filter and obtain matching Entities from the underlying
database based on the Query specified. Query implementations control
how a resulting JPQL gets constructed and which matching entities get
pulled, and can be easily extended.
To preserve compatibility with the existing Store interface, we can
mimick the existing ContinuumStore interface operations by having a
facade that can prepare requisite queries and delegate to a Store
instance.
3) Misc.
There are a few I am investigating:
1) Spring/Guice under the hood.
2) JUnit 4.4 (and Hamcrest library)
, but these are still in early stages.
I am keen to get a feedback on what others think.
Cheers,
Rahul
[1] -
http://svn.apache.org/repos/asf/maven/continuum/branches/continuum-jpa/
[2] - http://openjpa.apache.org/
[3] -
http://svn.apache.org/repos/asf/maven/continuum/branches/continuum-jpa/continuum-model-jpa/src/main/java/org/apache/maven/continuum/store/api/Store.java
Can't checkout trunk on Windows
Hi, There seems to be resources under: maven-embedder\src\test\error-reporting-projects\testReportUnresolvableArtifactWhileAddingExtensionPlugin\local-repo\org\apache\maven\errortest\testReportUnresolvableArtifactWhileAddingExtensionPlugin-maven-plugin that causes the checkout to fail under windows. Can someone on a non-windows box fix this please. Thanks, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-test-tools 1.0-alpha-2
Hi, Any idea what has changed from the last release for both maven-test-tools and maven-plugin-testing-tools? Rahul Brian E. Fox wrote: In preparation for some plugin releases, I'd like to release the next version of maven-test-tools (1.0-alpha-2) It is staged at: http://people.apache.org/~brianf/staging-repository Vote is open for 72hrs. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] separate issues@ list
+1 Brett Porter wrote: per the thread on [EMAIL PROTECTED] - should Archiva have it's own [EMAIL PROTECTED] list? [ ] +1 [ ] 0 [ ] -1 Cheers, Brett
Re: [vote] separate issues@ list
+1 On Dec 5, 2007 1:57 PM, Brett Porter <[EMAIL PROTECTED]> wrote: > per the thread on [EMAIL PROTECTED] - should Continuum have it's own [EMAIL > PROTECTED] > list? > > [ ] +1 > [ ] 0 > [ ] -1 > > Cheers, > Brett >
Re: [vote] Alexandru Popescu as a committer
+1 Cheers, Rahul Brett Porter wrote: Alex did the work to make TestNG support pretty much fully functional on Surefire trunk some months back and he and Dan Fabulich are now discussing this on the surefire-dev list and looking to complete the work. Alex is already a committer on Struts at Apache and one of the founders of TestNG itself. +1 from me Cheers, 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]
Re: [vote] Nicolas de Loof as a committer
+1 Rahul 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]
Re: adding video capture to the continuum site
How will this affect users on dial-up/slow connections browsing those pages on the continuum site? Is it possible to have these swf (or wnk) resources live outside SVN and be included from an external URL? Rahul - Original Message - From: "olivier lamy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 19, 2007 6:42 PM Subject: adding video capture to the continuum site Hi, I'd like to add some wink captures to the site (as adding a project for newbies etc...) As this files can be huge, I don't really want to add this in sources trunk (It can be long to checkout the sources) But in order to publish them, they must be in a site module. That's why I'd like to remove the site module from this current path and move it to https://svn.apache.org/repos/asf/maven/continuum/. svn mv https://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-site/ https://svn.apache.org/repos/asf/maven/continuum . The parent pom of this module will be last org.apache.maven:maven-parent pom. An other question is what I have to add in svn : wnk and swf files or only swf ? Let me know if there is any objections concerning this, -- Olivier
Re: svn commit: r571371 - /maven/site/trunk/src/site/apt/developers/committer-environment.apt
On 8/31/07, Lukas Theussl <[EMAIL PROTECTED]> wrote:
>
>
> Brett Porter wrote:
> > Sorry, I missed that. Your solution is definitely compliant with what
> > the APT "spec" says, so that's good.
> >
> > What might be nice is that doxia keeps track of all the anchor
> > references and throws an exception if the anchor is never found in the
> > document - that'll catch these much more easily than a link check.
>
> I'm not sure about that. First, it would only be a partial solution, as
> it would only work for internal links, for which an anchor has to exist
> within the same source document. For links to other files you always
> have to check whether the referenced file actually exists. Then, in a
> multi-module build, some links might only be valid after a site deploy,
> but never locally.
>
> But for local links we could issue a warning if the corresponding anchor
> is not found. Note however that it would have to be done by each parser
> separately (apt, xdoc), so it's likely not to be consistent for
> different input formats, and I don't think it will be that straight
> forward. A linkchecker would only operate on the final output files,
> independently of where they came from, so it's a more universal tool.
>
> Finally, IMO it's not doxia's job to check for valid user input at all
> (apart from parse exceptions if the source can't be parsed in the first
> place), that should really be done by an independent tool.
I agree here. I think it would be the responsibility of the Entity
that invokes the parser to take care of. It can delegate the link
validation to a linkchecker.
Can additional info (track of invalid anchors, links) be wrapped up in
the exceptions thrown and be bubbled up to Entity to make it easier to
run a linkcheck after the parser has finished execution. I am not
versed with Doxia internals but I am guessing it might work in case of
multi-module builds where the results are aggregated.
Cheers,
Rahul
>
> -Lukas
>
> >
> > Cheers,
> > Brett
> >
> > On 31/08/2007, at 5:10 PM, Lukas Theussl wrote:
> >
> >> It's part of a bug-fix: external links in apt files (ie links outside
> >> the current source document) have to start with './' or '../',
> >> otherwise I don't see how we could fix http://
> >> jira.codehaus.org/browse/DOXIA-47. We have implemented a hacky
> >> workaround for html files to preserve backward compat, but not for
> >> other file formats, like .txt, .pdf etc.
> >>
> >> I guess we should have pushed that for the beta-1 release of doxia
> >> because the behavior is not consistent now within alpha-9. But then,
> >> it's alpha...
> >>
> >> Btw, thanks rinku for fixing those links, I am currently working on
> >> the linkcheck port to m2 which will allow us to find these broken
> >> links more systematically (I'm sure there are more...)
> >>
> >> -Lukas
> >>
> >> Brett Porter wrote:
> >>
> >>> This is also a regression in doxia, then?
> >>> - Brett
> >>> On 31/08/2007, at 2:42 PM, [EMAIL PROTECTED] wrote:
> >>>
> Author: rinku
> Date: Thu Aug 30 21:42:23 2007
> New Revision: 571371
>
> URL: http://svn.apache.org/viewvc?rev=571371&view=rev
> Log:
> o fixed references to Eclipse and IDEA code formatter preferences.
>
> Modified:
> maven/site/trunk/src/site/apt/developers/committer- environment.apt
>
> Modified: maven/site/trunk/src/site/apt/developers/committer-
> environment.apt
> URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/
> developers/committer-environment.apt?
> rev=571371&r1=571370&r2=571371&view=diff
>
> ==
> --- maven/site/trunk/src/site/apt/developers/committer-
> environment.apt (original)
> +++ maven/site/trunk/src/site/apt/developers/committer-
> environment.apt Thu Aug 30 21:42:23 2007
> @@ -43,7 +43,7 @@
>
> * IntelliJ IDEA 4.5+
>
> - Download <<<{{{maven-idea-codestyle.xml}maven-idea-
> codestyle.xml}} >>> and copy it to
> + Download <<<{{{./maven-idea-codestyle.xml}maven-idea-
> codestyle.xml}}>>> and copy it to
> <<<~/.IntelliJIDEA/config/codestyles>>> then restart IDEA. On
> Windows, try
> <<\.IntelliJIDEA\config
> \codestyles>>>
>
> @@ -51,7 +51,7 @@
>
> * Eclipse 3.2+
>
> - Download <<<{{{maven-eclipse-codestyle.xml}maven-eclipse-
> codestyle.xml}}>>>.
> + Download <<<{{{./maven-eclipse-codestyle.xml}maven-eclipse-
> codestyle.xml}}>>>.
>
> After this, select Window \> Preferences, and open up the
> configuration for Java \> Code
> Style \> Code Formatter. Click on the button labeled Import...
> and select the file you
>
> >>> --
> >>> Brett Porter - [EMAIL PROTECTED]
> >>> Blog: http://www.devzuz.org/blogs/bporter/
> >>> -
> >>> To unsubscri
Re: [VOTE] Configure IDE plugins to download sources by default within Maven projects
Same here. +1 to Javadoc -1 to download sources Cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Wednesday, July 04, 2007 1:50 AM Subject: Re: [VOTE] Configure IDE plugins to download sources by default within Maven projects +1 to Javadoc -1 to sources (just a vote, not a veto :) On 03/07/2007, at 11:48 PM, Mark Hobson wrote: Following the recent thread "Maven POM plugin config", this is a vote to add downloadSources=true to both the eclipse and idea plugin configurations in the maven-parent POM: [ ] +1: I like Javadoc and easy debugging [ ] +0: I'll go with the flow [ ] -1: I like superfluous typing, guessing Javadoc and reading bytecode +1 from me. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r543579 - in /maven/components/trunk/maven-project/src: main/java/org/apache/maven/profiles/activation/JdkPrefixProfileActivator.java test/java/org/apache/maven/profiles/activation/Jdk
It can be configured here: Windows (menu) > Preferences (dialog) > Mylar (node) > Team (node) > Commit Comment Template You can invoke content assist to see the available Mylar variables using Ctrl + space within the comment editor text area. Cheers, Rahul John Casey wrote: Yes, it's what happens when you have a Mylar task open, and you commit a change. It seems like I've heard that it's adjustable, but I'm not entirely sure where/how. Since it seems that commit messages range across the board from none to the standard ASF format, I didn't think it was that big of a deal, provided the issue number was in there. Is it? -john On Jun 26, 2007, at 10:02 PM, Brett Porter wrote: John? On 02/06/2007, at 11:13 AM, Brett Porter wrote: On 02/06/2007, at 5:12 AM, [EMAIL PROTECTED] wrote: REOPENED - issue MNG-1910: Allow jdk 1.4+ as profile requirement http://jira.codehaus.org/browse/MNG-1910 Is this a mylar syntax or something? - 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] --- 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]
Re: Maven Diagram Maker
This is interesting. Might be a good idea to post these notes to the Wiki and keep the consolidated the discussion consolidated in one place. Rahul - Original Message - From: "Piotr Tabor" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Friday, May 11, 2007 11:22 PM Subject: Maven Diagram Maker I will create this summer (as a Google Summer of Code participant - with Jason van Zyl as a mentor) a software system that will allow, during the build process of a project, to automatically generate diagrams of chosen aspects of the project. I would like to start community discussion about the details - to provide very useful tool. I know - the mail is very long, but decisions made now will be essential. So: *please read and constructive comment*. I would like to provide two components: a graphical editor and a Maven plug-in. 'The Graphical Editor will offer live (WYSIWYG) preparation of a graphical presentation of the project by setting such properties as: - Type and subset of data, we want to present, - What part of the data is to be presented, - The method of presenting of each type of diagram nodes (that is, what attributes of the item will be displayed), and the general 'style' of the presentation. I would like to provide UML-like design. - The general layout algorithm - The positions of selected locked nodes – which we want to put in a fixed area. All other nodes will be positioned automatically. The schema of the diagram created by the editor will be saved to an XML file. Additionally the editor may be used as a graphical browser (explorer) of chosen aspects of the project. The editor will use the Prefuse library (http://prefuse.org). The Maven Plug-in (maven-graph-plugin) – will be using the XML file prepared by the Graphical Editor and the current state of project to prepare images in various graphic formats (JPG, TIFF, PNG and others supported by the Sun JAI library (http://java.sun.com/javase/technologies/desktop/media/jai/). The plug-in will be able to prepare the HTML tag for the picture too (to create an active area on web page containing the image). The resulting file will be ready to use in the next Maven phases by Doxia or other documenting tool. The maven-graph-plugin will cope with changes in the project made after generating the schema XML file. This means that if an object from the XML file is no longer exists in the project, it won't be visible in the picture. It also means that if the object is new, it will be placed in the picture (in a place calculated by the general layout strategy set in the XML file). Additionally the user will be warned about any discrepancies between the expected and actual data and problems with finding space for a new object. The diagram generation will not modify the XML file, but will only try to interpret it for the current situation. During Google Summer of Code time I wish I prepare two connectors (possibilities to visualize an aspect of project): - Dependencies diagram connector – to visualize the chosen project's subset of the dependencies (internal or external, up to a configured depth or/and included in a given scope). It will be also possible to exclude some dependencies from the diagram. - Class diagram – to visualize the inheritance and composition aspects of the class hierarchy. The information will be obtained by reflection. Of course the mechanism of the connectors will be universal enough to make the addition of a new aspect of a project as simple as possible. Why „Maven Diagram-Maker"? There are no good, free tools to prepare diagrams – especially such that would automatically generate diagrams from the source code and project descriptors. On the other hand, good and up-to-date documentation is a very important part of software development process – particularly in the Open Source world, where documentation is critical to help many people work on projects. On the other hand, nobody likes preparing documents and diagrams. To make the matters worse, using standard one-time diagrammers helps only for a short period of time. In fast growing projects, the pictures become obsolete very quickly. They start to mislead. Therefore I think that adding possibility to generate actual up-to-date diagrams in the build process is a very important idea – and Maven is the perfect environment to do that. Java developers can nowadays use very good text documenting tools, such a JavaDoc and Doxia, but the lack of methods to prepare and incorporate actual visual information in the documents is a very serious shortcoming of those tools. Planned editor features The Graphical Editor will help the user create and edit the visualization schema XML file. The file will contain two types of information: - The section will describe which data will be presented, that is - how to acquire the information to present. The classes and attributes of connectors, which will
Re: [VOTE] Release Maven 2.0.5 (take 2)
+1 Rahul Jason van Zyl wrote: Hi, The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/maven-core/2.0.5/ Here is the JIRA roadmap: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC +1 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]
Re: 2.0.5 and MNG-2794
+1 Yep, i guess this is going to become a FAQ on the list and on IRC :-) Rahul Brett Porter wrote: Sounds right to me. Needs something mentioned in the announcement/release notes, though. - Brett On 12/02/2007, at 9:25 AM, Jason van Zyl wrote: Hi, After looking at MNG-2794 I don't think it's something we should fix change. The 2.0.4 release was working in a way contrary to our documentation in that the nearest with 2.0.4 was not being selected and it is with 2.0.5. So we either fix it and then it conflicts with what we document, or leave it and have work as documented. That particular test case also requires commons-collections for compilation and you should always specify directly any dependencies you need to compile your project. The details are in the comment, but I say we leave the behavior that is present in 2.0.5 now. http://jira.codehaus.org/browse/MNG-2794#action_87295 Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plexus documentation
Hi, That (Plexus component list) is on the todo list for docs, but I haven't been able to get to it. Do you want to take this discussion to the Plexus list? I know there are a some gaps and would be interested in hearing what (else) you are looking for on the Plexus site. Cheers, Rahul nicolas de loof wrote: Just to make things clear, I now about the (nice) plexus documentation about HOW to write components. What I'm looking for is doc about available components (http://plexus.codehaus.org/ref/available-components.html) that may be really usefull 2007/2/7, nicolas de loof <[EMAIL PROTECTED]>: Hi guys, Just some generic questions about maven development and Plaexus : Plexus / Wagon and other technologies used by maven seems to re-invent the wheel, compared to existing projects (spring or pico, commons-vfs...) 1. Do maven developers hate code created elsewhere ;-) ? as documentation is really poor (is there some ?) it is difficult to know WHY a new project has been created and how it differs from existing ones. 2. I've found some interesting components in plexus (plexus-util) so I get frustrated not getting a better documentation about what plexus can offer. Is there some plan to get better doc ? How do you expect contributors to get involved in those components ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] merge id-refactor branch changes
These run without errors/failures after latest updates. Please let me know if you still encounter errors. Rahul - Original Message - From: "Emmanuel Venisse" <[EMAIL PROTECTED]> To: Sent: Wednesday, January 24, 2007 9:41 PM Subject: Re: [vote] merge id-refactor branch changes --- Test set: org.apache.continuum.web.test.AntTest --- Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 50.86 sec <<< FAILURE! testAddAntProject(org.apache.continuum.web.test.AntTest) Time elapsed: 16.5 sec <<< FAILURE! junit.framework.ComparisonFailure: expected:Summary> but was: at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.maven.shared.web.test.AbstractSeleniumTestCase.assertPage(AbstractSeleniumTestCase.java:217) at org.apache.continuum.web.test.AbstractContinuumTestCase.assertProjectGroupsSummaryPage(AbstractContinuumTestCase.java:159) at org.apache.continuum.web.test.AntTest.testAddAntProject(AntTest.java:36) Emmanuel Venisse a écrit : -1. some int/Integer in DefaultContinuum aren't converted to long so continuum-web-test fails. AntProjectTest fails due to a classcast exception in DefaultContinuum line 1186. Emmanuel Rahul Thakur a écrit : Hi, I'd like to request a vote to merge the id-refactor branch changes. 'int' ids are now converted to 'long' across the project and to allow really large values. This should cater to scenarios where the id generation could be started from an arbitrary large value. Cheers, Rahul
Re: [vote] merge id-refactor branch changes
Trygve Laugstøl wrote: Rahul Thakur wrote: 'int' ids are now converted to 'long' across the project and to allow really large values. This should cater to scenarios where the id generation could be started from an arbitrary large value. Won't this break the API? Yep, it would. What is the use case where 4 billion IDs isn't sufficient? 2 billion you mean :-). But this also more of something that I have noticed 'traditionally' that ids are specified as long and stored as bigints in database No, 4 billion. an int is +-2billion. Anyway, just because longs are more traditionally used that is not a good enough reason to switch to longs and break the API to me. Yep, I know, I was referring to the +ve 2 billions. I could say a case where Id generation could be set to start from a fairly large value and so are the Id sequence increments. One could argue this is an edge case ;-). IMHO the version change to 1.1 is a fair indication that the API might have changed. Having said that, I will go with whatever most of us think sounds practical :-) Cheers, Rahul -- Trygve
Re: [vote] merge id-refactor branch changes
'int' ids are now converted to 'long' across the project and to allow really large values. This should cater to scenarios where the id generation could be started from an arbitrary large value. Won't this break the API? Yep, it would. What is the use case where 4 billion IDs isn't sufficient? 2 billion you mean :-). But this also more of something that I have noticed 'traditionally' that ids are specified as long and stored as bigints in database. Rahul -- Trygve
Re: [vote] Collapse Maven permission groups
Is this formalized then? Rahul Brett Porter wrote: After the allotted 72 hours, the results stand as: Full proposal: 9 (7 PMC, 2 committers): Brett, Arnaud, Emmanuel, Trygve, Dennis, Fabrizio, Lukas, Rahul, Milos Partial proposal: 6 (6 PMC): Joakim, John T, Kenney, Jesse, John C, Jason Abstained: 3 (3 PMC): Mike, Vincent S, Stephane Against: None. Not yet voted: 3 PMC: Vincent M, Carlos, James This is in favour of the full proposal. I will follow up with the PMC about how we execute this. - Brett On 09/01/2007, at 10:50 AM, Brett Porter wrote: Hi, Since there was no objection to calling a vote, as discussed in the proposal, I'd like to call a vote on this. To see the proposal and discussion: http://mail-archives.apache.org/mod_mbox/maven-dev/200612.mbox/[EMAIL PROTECTED] Vote to operate as - requiring 2/3rds of the PMC to vote (13), with a majority within those votes for it to pass (ie, add them all and if the result is > 0). Other votes would be welcome with reasons as advisory, but not binding. - Votes can be changed at any time before result is posted. - Vote is open for at least 72 hours, completing once enough have voted after that. - There are two different +1 options. If there is a majority for "collapse all groups" against both other options, then it will pass. If it fails, then all votes will be transferred to the "retain subproject access restrictions" and recounted. The proposal is to collapse all access groups into a single ACL for Maven, with the following list of 37 committers: Fabrice Bellingard, David Blevins, John Casey, Maria Ching, Joakim Erdfelt, Dan Fabulich (pending), Brian Fox, Fabrizio Giustina, Arnaud Heritier, Jeff Jensen, Shinobu Kawai, Milos Kleint, Trygve Laugstol, Felipe Leme, Dennis Lundberg, Vincent Massol, Jesse McConnell, Stephane Nicoll, Mike Perham, Brett Porter, Edwin Punzalan, Daniel Rall, Allan Ramirez, Carlos Sanchez, Vincent Siveton, Wendy Smoak, Torbjorn Smorgrav, James Strachan, Chris Stevenson, Rahul Thakur, Lukas Theussl, John Tolentino, Dan Tran, Emmanuel Venisse, Kenney Westerhof, Andrew Williams, Henri Yandell, and Jason van Zyl. The alternate proposal is to retain subproject access restrictions, so the groups will be (PMC members removed, as they retain access to all areas): maven=wsmoak,felipeal,jjensen,shinobu,dlr,mkleint,handyande,epunzalan,aramirez,dantran,chrisjs,brianf,bellingard,oching (/maven-1,/components,/plugins,/archetype,/core-integration-testing,/jxr,/release,/skins,/resources,/release-testing) doxia=dblevins archiva=bayard,epunzalan,oching continuum=dblevins,rinku scm=dantran,smorgrav wagon= surefire= All of the above groups will have access to: /pom, /project, /site, /shared in this proposal, so it is essentially to collapse the @maven group, making the permission groups match the existence of a corresponding dev lists. [ ] +1 for the full proposal - collapse all groups (implies a vote for the next option if vote doesn't pass) [ ] +1 for the partial proposal - retain subproject access restrictions [ ] 0 abstain from vote [ ] -1 do not alter the current permissions Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r498929 - /maven/continuum/branches/id-refactor/pom.xml
There's a new method I added to it that allows 'long' instead of 'int' - Original Message - From: "Emmanuel Venisse" <[EMAIL PROTECTED]> To: Sent: Wednesday, January 24, 2007 4:53 AM Subject: Re: svn commit: r498929 - /maven/continuum/branches/id-refactor/pom.xml Why do you need it? [EMAIL PROTECTED] a écrit : Author: rinku Date: Mon Jan 22 22:02:35 2007 New Revision: 498929 URL: http://svn.apache.org/viewvc?view=rev&rev=498929 Log: o incremented plexus-jdo dep version. Modified: maven/continuum/branches/id-refactor/pom.xml Modified: maven/continuum/branches/id-refactor/pom.xml URL: http://svn.apache.org/viewvc/maven/continuum/branches/id-refactor/pom.xml?view=diff&rev=498929&r1=498928&r2=498929 == --- maven/continuum/branches/id-refactor/pom.xml (original) +++ maven/continuum/branches/id-refactor/pom.xml Mon Jan 22 22:02:35 2007 @@ -398,7 +398,7 @@ org.codehaus.plexus plexus-jdo2 -1.0-alpha-8 +1.0-alpha-9-SNAPSHOT org.codehaus.plexus
[vote] merge id-refactor branch changes
Hi, I'd like to request a vote to merge the id-refactor branch changes. 'int' ids are now converted to 'long' across the project and to allow really large values. This should cater to scenarios where the id generation could be started from an arbitrary large value. Cheers, Rahul
Re: [vote] release maven-changelog-plugin 2.0
+1 Rahul - Original Message - From: "Dennis Lundberg" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Saturday, January 20, 2007 12:08 PM Subject: [vote] release maven-changelog-plugin 2.0 Hi, I'd like to release the changelog. It has not had a release since it moved from Codehaus, so this will be the first release at Apache. A lot of issues have been resolved for 2.0 as can be seen in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11211&fixfor=12471 There are still 2 open issues, but I don't think they should hold back a release: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=11211&fixfor=-1 Revision: 497994 A snapshot has been deployed to the Apache snapshot repo: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-changelog-plugin/2.0-SNAPSHOT/maven-changelog-plugin-2.0-20070119.230232-7.jar The one thing left to do is to decide which parent pom to use. Currently maven-plugins-8-SNAPSHOT is used as a parent. Either we go back to maven-plugins-7 or release maven-plugins-8. WDYT? The vote will be open for 72 hours. Here is my +1 -- 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]
Re: short term branch for project/group keys
I am done with my changes on 'id-refactor' branch. The tests run fine without any errors. It would be great if others can take this for a spin as well. How does this gets merged back to trunk now? vote? Cheers, Rahul - Original Message - From: "Jesse McConnell" <[EMAIL PROTECTED]> To: Sent: Saturday, January 20, 2007 5:11 AM Subject: Re: short term branch for project/group keys sounds good :) On 1/18/07, Rahul Thakur <[EMAIL PROTECTED]> wrote: Hey Jesse, I am gonna fork a new branch tonight and get started on this change. Hopefully should be able to get the relevant stuff that we have already done merged on the core modules before we start playing with the other modules tomorrow :-) Cheers, Rahul Jesse McConnell wrote: > I am loathe to let a branch lay around for a long time with minimal > work being done actively on it and we learned what we wanted to > from > it in the short time we worked with it I think. > > my take-away was that the change the string based keys will be a > good > change but its large enough that it should be done in the context > of > some other refactoring and changes. > > as for the int->long id change, I think its a good thing and will > focus us to address the database upgrading issue so its all good > imo > :) > > jesse > > On 1/16/07, Rahul Thakur <[EMAIL PROTECTED]> wrote: >> >> Jesse and myself had a chat yesterday morning about the >> key-refactoring >> branch that we spun before Christmas last year, and we reckon that >> it >> might be an idea to get 1.1-alpha rolling and meantime gather more >> thoughts around Groupings (introduce versions/tags). We think >> having >> String-based keys for groups might be more feasible for v1.2. >> >> However, we are keen to bring over the API changes where the 'int' >> Ids >> are now converted to 'long'. Some other bits like breaking up the >> existing Project and ProjectGroup interfaces can be continued on >> the >> trunk itself after the merge. >> >> What do others think? >> >> Cheers, >> Rahul >> >> - Original Message - >> From: "Jesse McConnell" <[EMAIL PROTECTED]> >> To: >> Sent: Friday, December 22, 2006 8:30 AM >> Subject: short term branch for project/group keys >> >> >> >I am thinking about pulling a short term branch of continuum with >> > rahul and working on getting everything converted to using a >> > string >> > based key project and project group reference in all apis and in >> > all >> > of the UI decision making items. He has tomorrow off so I think >> > that >> > unless anyone has any big issues with it we'll try and make that >> > branch and work on it tomorrow. >> > >> > the end result of it would be: >> > >> > * int id's for project and project group in the model are for >> > internal >> > store usage >> > * name's for project and project group are for presentation >> > purposes >> > only >> > * key's are for all api usage and passing around un URL's etc. >> > >> > some quick benefits are: >> > >> > * consistency across all apis and url manipulations >> > * ability to add quick url rewriting for direct linking of >> > projects >> > foo.org/Doxia/Core >> > * common keys across running continuum instances for clustering >> > >> > jesse >> > >> > -- >> > jesse mcconnell >> > [EMAIL PROTECTED] >> >> > > -- jesse mcconnell [EMAIL PROTECTED]
Re: short term branch for project/group keys
Hey Jesse, I am gonna fork a new branch tonight and get started on this change. Hopefully should be able to get the relevant stuff that we have already done merged on the core modules before we start playing with the other modules tomorrow :-) Cheers, Rahul Jesse McConnell wrote: I am loathe to let a branch lay around for a long time with minimal work being done actively on it and we learned what we wanted to from it in the short time we worked with it I think. my take-away was that the change the string based keys will be a good change but its large enough that it should be done in the context of some other refactoring and changes. as for the int->long id change, I think its a good thing and will focus us to address the database upgrading issue so its all good imo :) jesse On 1/16/07, Rahul Thakur <[EMAIL PROTECTED]> wrote: Jesse and myself had a chat yesterday morning about the key-refactoring branch that we spun before Christmas last year, and we reckon that it might be an idea to get 1.1-alpha rolling and meantime gather more thoughts around Groupings (introduce versions/tags). We think having String-based keys for groups might be more feasible for v1.2. However, we are keen to bring over the API changes where the 'int' Ids are now converted to 'long'. Some other bits like breaking up the existing Project and ProjectGroup interfaces can be continued on the trunk itself after the merge. What do others think? Cheers, Rahul - Original Message - From: "Jesse McConnell" <[EMAIL PROTECTED]> To: Sent: Friday, December 22, 2006 8:30 AM Subject: short term branch for project/group keys >I am thinking about pulling a short term branch of continuum with > rahul and working on getting everything converted to using a string > based key project and project group reference in all apis and in all > of the UI decision making items. He has tomorrow off so I think that > unless anyone has any big issues with it we'll try and make that > branch and work on it tomorrow. > > the end result of it would be: > > * int id's for project and project group in the model are for internal > store usage > * name's for project and project group are for presentation purposes > only > * key's are for all api usage and passing around un URL's etc. > > some quick benefits are: > > * consistency across all apis and url manipulations > * ability to add quick url rewriting for direct linking of projects > foo.org/Doxia/Core > * common keys across running continuum instances for clustering > > jesse > > -- > jesse mcconnell > [EMAIL PROTECTED]
Re: [VOTE] Release compiler plugin 2.0.2
+1 Rahul Jesse McConnell wrote: +1 On 1/17/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: +1 - Joakim Carlos Sanchez wrote: > It fixes a couple of annoying issues for windows users > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11130&fixfor=12484 > > > One question, can the 2.0.x branch no longer needed be deleted to > avoid confusion? > https://svn.apache.org/repos/asf/maven/plugins/branches/maven-compiler-plugin-2.0.x > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cant run from trunk
Same error here with latest SVN update. Rahul - Original Message - From: "Marcelo Fukushima" <[EMAIL PROTECTED]> To: Sent: Sunday, January 14, 2007 2:54 PM Subject: Re: cant run from trunk so everybodu else is able to run the current trunk? only i am having trouble? On 1/13/07, Erik Bengtson <[EMAIL PROTECTED]> wrote: I suggest you to try out the upcoming JPOX 1.1.6 (since 1.1.3 it's more than 40 fixes). It will be out in about 2 weeks. Quoting Marcelo Fukushima <[EMAIL PROTECTED]>: > hello devs (here i am yet another annoying email) > > it all started while i was trying to fix a bug > (http://jira.codehaus.org/browse/CONTINUUM-1103)... while i was > doing > that, ive found out that the jpox 1.1.1 created wrong queries (its > even commented as a weird thing) > after upgrading its version to 1.1.3, it passes the TestCase but > continuum would not run... after spending some time with it, ive > noticed that the error has nothing to do with jpox, but its rather > related to a plexus config file: > > Caused by: > org.codehaus.plexus.component.repository.exception.ComponentRepositoryException: > Component descriptor role: > 'org.apache.maven.wagon.providers.ssh.knownhost.KnownHostsProvider', > implementation: > 'org.apache.maven.wagon.providers.ssh.knownhost.FileKnownHostsProvider', > role hint: 'file' has a hint, but there are other implementations > that > don't > > weird... but after going back to 1.1.1, i get the very same > error... > and after checking out the code from trunk, i still get the same > error... > > i went to that config file (inside wagon-ssh), and ive found this: > > > > org.apache.maven.wagon.providers.ssh.knownhost.KnownHostsProvider > file > > org.apache.maven.wagon.providers.ssh.knownhost.FileKnownHostsProvider > per-lookup > > ask > > > > > org.apache.maven.wagon.providers.ssh.knownhost.KnownHostsProvider > null > > org.apache.maven.wagon.providers.ssh.knownhost.NullKnownHostsProvider > per-lookup > > ask > > > > > im thinking that that might be the problem (the nullHostProvider), > but > im not sure as i dont know much about plexus... > is noone else having the same problem? have anyone else ever had > that > problem? > sorry for the long mail... > -- > regards > Marcelo Takeshi Fukushima > -- []'s Marcelo Takeshi Fukushima
Re: continuum-store and JDO
Marcelo Fukushima wrote: On 1/11/07, Rahul Thakur <[EMAIL PROTECTED]> wrote: Marcelo Fukushima wrote: > yeah... > but now that ive settled it, ive encountered a new set of probs, this > time in the data-management with the trunk on svn: > -while backing up the continuum store, a FileWriter is used (wich uses > default system char encoding), but the stream used to write the xml > tries to use utf-8, in wich case an exception is thrown; This is a known issue. I think its to do with locale settings. ive attached a patch that i think solves this one (it actually uses the same charset encoding in the writer by using a OutputStreamWriter ( FileOutputStream, Charset ) i know this test passes to me now but itd be great if anyone else could test it in a diff env (maybe other jdks and os's) http://jira.codehaus.org/secure/ManageAttachments.jspa?id=45956 Thanks! I will take it for a spin (hopefully shortly) though i am on Windows XP as well. Yep, it might be a good idea if we can get it to run on another machine as well. > -the backup file (an xml) is compared to a hard coded xml file... but > at least with my dev env (win xp with jdk6), some child nodes are > swaped... You mean the nodes _do_ exist _but_ in a different order. Can you point me to the test that is showing this behaviour? exactly... ill generate it again, but i think the id tag gets switched... its in the DataManagementToolTest inside the continuum-data-management module Cool, will have a look when I get back home. I came across a different behaviour with HashMap key ordering in JDK 6. I suspect if its something similar in this case. btw i cant seen to compile from maven: it gives me an Access Denied Exception on some random directories (im compiling and running the tests from inside eclipse) Do you have continuum checkout on your drive's root or nested a few levels in another directory ? Rahul Cheers, Rahul > > the first one is most certainly a bug (and i already have a fix), > while the second one im not so sure so i wanted to ask yall first > > regards, > takeshi > > On 1/11/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: >> windows path length pb? >> >> Marcelo Fukushima a écrit : >> > im looking into it, but i cant seen to install the modules locally - >> > im getting a weird random access denied error... >> > >> > >> > On 1/10/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: >> >> Yes. A global patch would be better instead of separate patches. >> >> I tried your 2 patches and updated locally jpox-* to 1.1.3 in >> >> continuum parent pom. With them, all tests works fine, but continuum >> >> doesn't start. >> >> >> >> Emmanuel >> >> >> >> Marcelo Fukushima a écrit : >> >> > Hello dear devs. >> >> > >> >> > After everyone's help, ive noticed that jpox was saving the >> >> > BuildDefinition with wrong values (the buildFresh and arguments and >> >> > possibly others too)... since i dont know how jpox work, the first >> >> > thing i tried was to update to a more recent version of it (namely >> >> > 1.1.3) and everything worked fine... >> >> > im going to attach the test case to jira (actually a patch to the >> >> > testcase to check those things too), but should i attach a patch to >> >> > the pom too? >> >> > >> >> > On 1/9/07, Brett Porter <[EMAIL PROTECTED]> wrote: >> >> >> The metadata file (and enhanced classes) are generated when you >> use >> >> >> Maven to build the project. As long as eclipse doesn't >> overwrite the >> >> >> class files it should be fine. Alternatively, you can use the >> eclipse >> >> >> plugin for jpox to make sure the classes get enhanced and just run >> >> >> maven once to generate the metadata file. I've never used that >> >> >> plugin, but it is available from the jpox site. >> >> >> >> >> >> Thanks! >> >> >> - Brett >> >> >> >> >> >> On 09/01/2007, at 2:27 PM, Marcelo Fukushima wrote: >> >> >> >> >> >> > hello folks! i sent a couple of emails to the user list, but i >> >> guess i >> >> >> > could help a little too, right? so i just checked out the >> code from >> >> >> > SVN and wanted to tackle >> >> >> > http://jira.codehaus.org/browse/CONTINUUM-1103 >> >> >> > while i could isolate the bug (the property is not getting >> persisted >> >> >> > on the db) but since i know almost nothing about jdo, i cant >> run the >> >> >> > tests inside eclipse to try to figure out the solution and i >> couldnt >> >> >> > find where the metadata file or the enhanced version of the >> classes >> >> >> > are found... >> >> >> > is there any doc that can help me with that kinda of info? >> thanks >> >> >> > in advance >> >> >> > -- >> >> >> > []'s >> >> >> > Marcelo Takeshi Fukushima >> >> >> >> >> > >> >> > >> >> >> >> >> > >> > >> >> > >
Re: continuum-store and JDO
Marcelo Fukushima wrote: yeah... but now that ive settled it, ive encountered a new set of probs, this time in the data-management with the trunk on svn: -while backing up the continuum store, a FileWriter is used (wich uses default system char encoding), but the stream used to write the xml tries to use utf-8, in wich case an exception is thrown; This is a known issue. I think its to do with locale settings. -the backup file (an xml) is compared to a hard coded xml file... but at least with my dev env (win xp with jdk6), some child nodes are swaped... You mean the nodes _do_ exist _but_ in a different order. Can you point me to the test that is showing this behaviour? Cheers, Rahul the first one is most certainly a bug (and i already have a fix), while the second one im not so sure so i wanted to ask yall first regards, takeshi On 1/11/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: windows path length pb? Marcelo Fukushima a écrit : > im looking into it, but i cant seen to install the modules locally - > im getting a weird random access denied error... > > > On 1/10/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: >> Yes. A global patch would be better instead of separate patches. >> I tried your 2 patches and updated locally jpox-* to 1.1.3 in >> continuum parent pom. With them, all tests works fine, but continuum >> doesn't start. >> >> Emmanuel >> >> Marcelo Fukushima a écrit : >> > Hello dear devs. >> > >> > After everyone's help, ive noticed that jpox was saving the >> > BuildDefinition with wrong values (the buildFresh and arguments and >> > possibly others too)... since i dont know how jpox work, the first >> > thing i tried was to update to a more recent version of it (namely >> > 1.1.3) and everything worked fine... >> > im going to attach the test case to jira (actually a patch to the >> > testcase to check those things too), but should i attach a patch to >> > the pom too? >> > >> > On 1/9/07, Brett Porter <[EMAIL PROTECTED]> wrote: >> >> The metadata file (and enhanced classes) are generated when you use >> >> Maven to build the project. As long as eclipse doesn't overwrite the >> >> class files it should be fine. Alternatively, you can use the eclipse >> >> plugin for jpox to make sure the classes get enhanced and just run >> >> maven once to generate the metadata file. I've never used that >> >> plugin, but it is available from the jpox site. >> >> >> >> Thanks! >> >> - Brett >> >> >> >> On 09/01/2007, at 2:27 PM, Marcelo Fukushima wrote: >> >> >> >> > hello folks! i sent a couple of emails to the user list, but i >> guess i >> >> > could help a little too, right? so i just checked out the code from >> >> > SVN and wanted to tackle >> >> > http://jira.codehaus.org/browse/CONTINUUM-1103 >> >> > while i could isolate the bug (the property is not getting persisted >> >> > on the db) but since i know almost nothing about jdo, i cant run the >> >> > tests inside eclipse to try to figure out the solution and i couldnt >> >> > find where the metadata file or the enhanced version of the classes >> >> > are found... >> >> > is there any doc that can help me with that kinda of info? thanks >> >> > in advance >> >> > -- >> >> > []'s >> >> > Marcelo Takeshi Fukushima >> >> >> > >> > >> >> > >
Re: calling vote for 2.0.5
Jason van Zyl wrote: On 11 Jan 07, at 1:16 PM 11 Jan 07, Rahul Thakur wrote: +1 for releasing 2.0.5 +0 for micro releases. I agree with Trygve's comment that too frequent of these can lead to inconsistent developer environments. Really the point is to schedule them and make the roadmaps available so that people can take them if they choose. Yep, I understand the intent and that is good. A reasonable interval(?) for micro releases should be fine. If I had a team I probably wouldn't grab a micro release every week, but I might take one monthly or take one that had a fix in it I needed. Yes, you do have a team (teams even) ! ;-) Rahul I wouldn't expect people to consume them constantly, I just want to make the fixes available more frequently in an official form so people can use them. Jason. Cheers, Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, January 11, 2007 11:20 AM Subject: calling vote for 2.0.5 Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
+1 for releasing 2.0.5 +0 for micro releases. I agree with Trygve's comment that too frequent of these can lead to inconsistent developer environments. Cheers, Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, January 11, 2007 11:20 AM Subject: calling vote for 2.0.5 Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. 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]
Re: deploy surefire snapshot
hehe so this is why releases were failing at my end! Rahul Kenney Westerhof wrote: Prasad Kashyap wrote: I suspect this to be the cause of my woes :-) [INFO] [INFO] Surefire report directory: C:\Apache\geronimo\trunk\testsuite\deployment-testsuite\deployment-tests\target\surefire-reports [INFO] java.lang.NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter [INFO] Exception in thread "main" [INFO] [ERROR] There are test failures. Hi, I just solved this by deploying the surefire plugin itself. The version should be *-9.jar now. -- kenney My tests used to work fine just until recently. I use the 2.3-SNAPSHOT of maven-surefire-plugin. The latest jar in the repo is maven-surefire-plugin-2.3-20070110.125545-8.jar The surefire-booter that it depends on is a 2.1-SNAPSHOT and the latest timestamped jar in the repo is surefire-booter-2.1-20070108.094711-10.jar Cheers Prasad On 1/8/07, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: done On 1/8/07, Tom Huybrechts <[EMAIL PROTECTED]> wrote: > Hi, > > Could somebody deploy a surefire snapshot (including the > surefire-junit4 provider) ? > > thanks, > > Tom > > - > 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]
Re: [proposal] consolidate sandboxes
I think it makes sense to have these modules consolidated under one umbrella. +1 Cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Tuesday, January 09, 2007 10:38 AM Subject: [proposal] consolidate sandboxes Hi, When we earlier opened the Maven sandbox to all ASF committers, I think it was the intention to do this for all sandboxes, but that wasn't the case in practice. To have a cleaner ACL, and cleaner externals on /trunks, I'd like to propose we consolidate the sandboxes. The structure would be: /maven/sandbox /maven /benchmark (from /sandbox) /maven-1.x-integration (from /sandbox) /shared /maven-artifact-tools (from /sandbox) /maven-repository-checker (from /sandbox) /maven-shared-jar (from /sandbox) /maven-shared-java-parser (from /sandbox) /maven-shared-license (from /sandbox) /plugins (as now) /other /acm (from /sandbox) /grafo (from /sandbox) /issue (from /sandbox) /marmalade (from /sandbox) /maven-dynamic-web (from /sandbox) /maven-metamorphosis (from /sandbox) /reports (from /sandbox) /ssh-tester (from /sandbox) /taxonomy (from /sandbox) /wiki (from /sandbox) /wagon /wagon-scm (from /sandbox) /scm (from /scm/trunk/sandbox) /surefire (from /surefire/trunk/sandbox) /doxia (from /doxia/trunk/sandbox) /continuum (from /continuum/sandbox) /archiva (from /archiva/sandbox) /maven-1-plugins (from /maven-1/plugins-sandbox) Thoughts? 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]
Re: continuum-store and JDO
The metadata mapping (.jdo) file can be found under target/generated-classes/META-INF when you run: > mvn clean install on continuum-model. Besides, you can also choose to enhance the model class explicitly by > mvn jpox:enhance I have seen some annoyances running tests in Eclipse, most of them pertain to enhanced classes not being on classpath. I usually ensure that continuum-model JAR is sourced from the local M2 repo. HTH, Rahul Marcelo Fukushima wrote: hello folks! i sent a couple of emails to the user list, but i guess i could help a little too, right? so i just checked out the code from SVN and wanted to tackle http://jira.codehaus.org/browse/CONTINUUM-1103 while i could isolate the bug (the property is not getting persisted on the db) but since i know almost nothing about jdo, i cant run the tests inside eclipse to try to figure out the solution and i couldnt find where the metadata file or the enhanced version of the classes are found... is there any doc that can help me with that kinda of info? thanks in advance
Re: [vote] Collapse Maven permission groups
+1 for the full proposal - collapse all groups (implies a vote for the next option if vote doesn't pass) Rahul Brett Porter wrote: On 09/01/2007, at 10:50 AM, Brett Porter wrote: [X] +1 for the full proposal - collapse all groups (implies a vote for the next option if vote doesn't pass) [ ] +1 for the partial proposal - retain subproject access restrictions [ ] 0 abstain from vote [ ] -1 do not alter the current permissions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
+1 Rahul Carlos Sanchez wrote: On 1/8/07, Brett Porter <[EMAIL PROTECTED]> wrote: On 27/12/2006, at 8:50 AM, Brett Porter wrote: > 1) Establish a list of emeritus committers. ok, this has been taken care of. I've added myself a todo to document what we have in place. > 2) Remove inter-project commit restrictions > > The first does not depend on the second. But I think the second > does depend on the first. I would like to put each to a separate > vote once all the pros and cons have been gathered from this > discussion. I'd expect each vote to operate as requiring 2/3rds of > the PMC to vote (12), with a majority of +1's within those votes > for it to pass. Other votes would be welcome with reasons as > advisory, but not binding. This is still pending. We've had some discussions on both sides, with the general trend towards being in favour - but haven't heard from a large number of people. Does anyone have anything else to add? I'm +1 I don't think anybody will touch something before talking to other people Are there any objections to calling a vote and abiding by the result given the process above? (though it's now 13 votes required after the addition of John, and I also intended to keep it open 72 hours regardless so that folks have an opportunity to change their vote). > > * Removing restrictions > > The list of groups we have can be seen here: http:// > people.apache.org/~jim/projects.html. There are a lot. (the page is > currently down, unfortunately) > > Currently, only PMC members can commit to anything. > > Rather than using this technological boundary, which can be a > hindrance, I'd rather use a social boundary. That is, if you don't > quite know what you are doing but would like to try something new, > or want to make a big change in something you don't regularly > commit to - ask first. Perhaps create a branch and have the regular > committers review it first. > > I look forward to hearing your comments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Establish a list of emeritus committers
+1 Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, January 04, 2007 7:58 PM Subject: [vote] Establish a list of emeritus committers Hi, Vote to operate as - requiring 2/3rds of the PMC to vote (13), with a majority within those votes for it to pass (ie, add them all and if the result is > 0). Other votes would be welcome with reasons as advisory, but not binding. - Votes can be changed at any time before result is posted. - Vote is open for at least 72 hours, completing once enough have voted after that. I propose to establish a list of emeritus committers. - Someone can request to be made emeritus at any time they want - They will be listed as past members of the team (we will set up a special page for this), but have no karma. - An emeritus committer can request commit access again at any time they feel they can be active, and a vote will be held to accept them or not. - PMC members will not be made emeritus (unless they chose to stand down from the PMC). To start with, anyone who hasn't committed in 12 months will be made automatically emeritus. ie, this vote is to make the following people emeritus: - Pete Kazmier - Peter Lynch - Tom Copeland - Dan Diephouse - Alex Karasulu - Ben Walding - Daniel Rall - David Eric Pugh - Geir Magnusson Jr - Kasper Nielsen - Kurt Schrader - Stephane Mor - Bob McWhirter - Peter Donald - Peter Royal - Johnny R. Ruiz III [ ] +1, establish list of emeritus committers [ ] +0, abstain [ ] -1, do not establish a list of emeritus committers 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]
Re: [vote] Barrie Treloar as a Maven Plugins committer
+1 Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, January 04, 2007 3:58 PM Subject: [vote] Barrie Treloar as a Maven Plugins committer I'd like to propose we make Barrie a committer. He has contributed a lot of small patches, and recently seems to be the "does it work on Windows?" watchdog. He in particular has done a lot with the assembly plugin and has also dug into some of the components in Plexus to fix things where necessary. Very active on the developer and users lists. [ ] +1 Yes [ ] 0 Abstain [ ] -1 No/not yet 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]
Re: [discuss] iBatis, JPA and Java 5.0
Hi Erik, I am playing around refactoring some store stuff using jdo and ibatis on a separate branch (key-refactoring) and welcome any help i can get with JDO :-). I am usually on #continuum on IRC (irc.codehaus.org), or happy to join jpox lists. Cheers, Rahul Erik Bengtson wrote: Quoting Jason van Zyl <[EMAIL PROTECTED]>: JDO is not bad, but JPOX has proven to be less then robust. Sometime ago I joined this list to provide an easier a communication channel for solving continuum/jpox issues and besides a few emails no one has ever requested any help on issues neither gave any feedback. JPOX is the only implementation that passes JDO 2 TCK, and less than robust argument does not sounds fair since you dont even ask for help. Regards, Erik Bengtson
[discuss] iBatis, JPA and Java 5.0
These buzzwords have been making rounds on IRC and dev list :-), and after slight digging around I found a reference to a similar discussion here: http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/msg01251.html Agreed that the store implementation for Continuum should be pluggable, and if we are rethinking JPOX, then IMHO it might be worth taking into account JPA and Java 5.0. What do others think? Cheers, Rahul
Re: short term branch for project/group keys
Store updates: I am taking a stab at refactoring the current ContinuumStore into RefactoredContinuumStore as a p-o-c for a couple of things. 1) Idea basically is that the Store interface should provide (lookup, save and delete) operations on key 'application' entities. I gather these are o Project o ProjectGroup o Schedule o Profile o Installation o SystemConfiguration Updates to any children hanging off key entities should cascade. So, something like: addBuildDefinitionToProject addBuildDefintionToGroup could be done like: project.addBuildDefintion(updatedBuildDefintion); store.saveProject(project); and, group.addBuildDefinition(updatedBuildDefinition); store.saveProjectGroup(group); 2) Another thing that Jesse mentioned in his email about breaking up Continuum interface into two or three - I am thinking perhaps it might be an idea to break up the ContinuumStore into as many as well and have one-to-one mapping between store and corresponding continuum interfaces. So, possibly oProjectStore (all project related operations) oGroupStore (all group related operations) oSystemStore (all top level operations - fetch all projects, groups. Operations on Schedules, profiles etc) The names above are just indicative, we can change them later :-) Thoughts? Cheers, Rahul - Original Message - From: "Jesse McConnell" <[EMAIL PROTECTED]> To: Sent: Wednesday, December 27, 2006 10:28 AM Subject: Re: short term branch for project/group keys rahul and I have been talking on skype some working out some of the details of this key refactor and we see an opportunity to do a few things that might make life better for continuum. He is going to mail soon on some things that we are wanting to do in the store and this mail is one something to do with the DefaultContinuum object itself. I am thinking of breaking up the Continuum interface into two objects (perhaps three) interfaces that have more targeted purposes. Looking through the Continuum interface right now it has largely three purposes. 1) top lvl actions (getting all projects, building all projects, firing off adding of groups based on metadata, etc) 2) group actions (adding notifiers to groups, build definitions, etc) 3) project actions (adding notifiers to projects, build definitions, etc) In many methods for 2 and 3 the continuum instance is just acting as a facade over the store api doing lots of pass through function calls. Some places in continuum project shun the use of the Continuum interface for these things and just use the store api directly having plexus inject the ContinuumStore instance into the components. If you look at the Continuum interface as it stands right now there are a number methods like addBuildDefinition <- deprecated addBuildDefinitionToProject addBuildDefintionToGroup Rahul is going to mail on how this can be cleaned up in the store api, but I question why we want these methods on the Continuum interface at all? My thought at the moment is to take methods like 'getBuildDefinitionForGroup' and move those to an interface for group related actions that can't be directly on the ProjectGroup model class. Then perhaps do the same for the 'getBuildDefinitionForProject' type methods. This would solidify the focus of the Continuum interface to be a lookup for particular project group's and project's as well as top lvl continuum functionalities like building all projects using the ProjectSorter, etc. The we would have a ContinuumGroup and ContinuumProject interface and impl that could act as facade's over the model classes and some of the other logic oriented methods that are currently in the Continuum interface. thoughts? rahul and I are pretty happy with the way it sounds atm jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: short term branch for project/group keys
[snip] the project.id and projectGroup.id will basically disappear from continuum, reserved strictly for the underlying store. The store can do whatever it wants with them. Ok, so a project(Group)? will have: id : int key : String name : String ... Where key is used as a reference, id is used as a datastore/model identity, and name is used as a display. Sounds good. We could then have a table of "old names": id : int oldKey : String These could be used so that failed lookup on a key could then look in the old key's to find out what the new one is (like when you move an issue in JIRA). I'm not sure this is needed initially - only if we support picking up renames to the project itself. [/snip] That was my point in my last email. I understand why we need that "old key" table but this would be something that will just get bloated over time. There could be a 'housekeeper' process that can clean up old keys after a certain time has expired. I don't see a reason why we need to keep the old stuff for long. Cheers, Rahul
Re: [M2][maven-plugin-testing-harness] Lookup for custom Mocks
On a related note, can the Plugin harness notes at the URL below be updated for the recent updates to the harness and shared tools: http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Harness Thanks a ton in advance! Rahul - Original Message - From: "Raphaël Piéroni" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Monday, December 18, 2006 9:20 AM Subject: [M2][maven-plugin-testing-harness] Lookup for custom Mocks Hi, In a plugin i experiment with the testing harness. I would like to know how to configure the remote repositories and settings file. The plugin should be run in a directory without a pom.xml file. Regards, Raphaël - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update: Re: [vote] maven release process ( gpg / javadoc / site / source / remote-resources ) plugins.
I observed this afternoon that: source:jar and javadoc:jar goals were failing when I attempted a release. The versions in questions were 2.0.2 and 2.2 respectively. Attaching the error below. Anyone else noticed this? Rahul this realm = plexus.core.maven urls[0] = file:/D:/rnd/apps/maven-2.0.4/lib/commons-cli-1.0.jar urls[1] = file:/D:/rnd/apps/maven-2.0.4/lib/commons-httpclient-2.0.2.jar urls[2] = file:/D:/rnd/apps/maven-2.0.4/lib/commons-logging-1.0.3.jar urls[3] = file:/D:/rnd/apps/maven-2.0.4/lib/doxia-sink-api-1.0-alpha-7.jar urls[4] = file:/D:/rnd/apps/maven-2.0.4/lib/effacy-wagon-dav-1.0.jar urls[5] = file:/D:/rnd/apps/maven-2.0.4/lib/jsch-0.1.24.jar urls[6] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-artifact-2.0.4.jar urls[7] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-artifact-manager-2.0.4.jar urls[8] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-core-2.0.4.jar urls[9] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-error-diagnostics-2.0.4.jar urls[10] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-model-2.0.4.jar urls[11] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-monitor-2.0.4.jar urls[12] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-plugin-api-2.0.4.jar urls[13] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-plugin-descriptor-2.0.4.jar urls[14] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-plugin-parameter-documenter-2.0.4.jar urls[15] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-plugin-registry-2.0.4.jar urls[16] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-profile-2.0.4.jar urls[17] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-project-2.0.4.jar urls[18] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-reporting-api-2.0.4.jar urls[19] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-repository-metadata-2.0.4.jar urls[20] = file:/D:/rnd/apps/maven-2.0.4/lib/maven-settings-2.0.4.jar urls[21] = file:/D:/rnd/apps/maven-2.0.4/lib/plexus-interactivity-api-1.0-alpha-4.jar urls[22] = file:/D:/rnd/apps/maven-2.0.4/lib/wagon-file-1.0-alpha-7.jar urls[23] = file:/D:/rnd/apps/maven-2.0.4/lib/wagon-http-lightweight-1.0-alpha-6.jar urls[24] = file:/D:/rnd/apps/maven-2.0.4/lib/wagon-provider-api-1.0-alpha-6.jar urls[25] = file:/D:/rnd/apps/maven-2.0.4/lib/wagon-ssh-1.0-alpha-7.jar urls[26] = file:/D:/rnd/apps/maven-2.0.4/lib/wagon-ssh-external-1.0-alpha-6.jar urls[27] = file:/d:/rnd/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar urls[28] = file:/d:/rnd/repository/com/effacy/maven/m2/wagon/providers/wagon-dav/1.0/wagon-dav-1.0.jar urls[29] = file:/d:/rnd/repository/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar Number of imports: 0 this realm = plexus.core urls[0] = file:/D:/rnd/apps/maven-2.0.4/core/plexus-container-default-1.0-alpha-9.jar urls[1] = file:/D:/rnd/apps/maven-2.0.4/core/plexus-utils-1.1.jar Number of imports: 0 - [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.2:jar': Unable to find the mojo 'org.apach e.maven.plugins:maven-javadoc-plugin:2.2:jar' in the plugin 'org.apache.maven.plugins:maven-javadoc-plugin' org/codehaus/plexus/archiver/AbstractArchiver [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.2:jar': Unable to find the mojo 'org.apache.maven.plugins:maven-javadoc-plugin:2.2:jar' in the plugin 'org.apache.maven.plugins:maven-javadoc-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:538) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.
Re: [vote] release maven-ear-plugin (second try)
+1 - Original Message - From: "Stephane Nicoll" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Sunday, December 17, 2006 8:28 AM Subject: [vote] release maven-ear-plugin (second try) 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]
Re: The Future of the Release Process.
Joakim Erdfelt wrote: This is just a synopsis email about the future of the release process. Disclaimer: I am not attempting to set policy, just to get discussion going, document it, and work towards the ideal toolchain that make the future of apache releases smooth, consistent, and resilient Desired End Goal: This discussion will revolve around the apache process for official releases of projects. 1) Releases are non-SNAPSHOT. 2) All releases shall be voted on. * Call a vote on the appropriate dev@ mailing list. * Wait 72 hours. * If unanimous +1 vote by 7 or more PMC members, then release can occur before 72 hour window is up. * Document the following in the vote: a) Project Name b) Project Version in Subversion. c) Desired Release Version ID. d) Expected Next Development Version ID. e) Age of development version (days since last non-snapshot release) f) Downstream snapshot dependencies that might cause problems. g) Jiras that have been closed/resolved for this release. f) Tasks that have been completed in SCM but do not appear in the Jira completion list. g) URL to jira completion report for this version. h) SCM revision being voted on. * If a change occurs to the project, the vote should be updated with the change and a new vote started. (this resets the 72 hours) This only consitutes changes that occur in the project itself, not downstream dependencies. [snip/] I think we should have (2-g) and (2-f) above included as/in Release Notes. Release notes can be deployed to the repo along with other artifacts, so: * foo-1.0.pom(pom / metadata for artifact) * foo-1.0.jar(actual binary artifact) * foo-1.0-sources.jar(source code for artifact) * foo-1.0-javadoc.jar(javadoc for artifact) * foo-1.0-release-notes.txt (updates/features in the artifact) Cheers, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] build failure, Version: test ??? error
did you find what was causing it? :-) Barrie Treloar wrote: On 12/13/06, Rahul Thakur <[EMAIL PROTECTED]> wrote: If i remember correct from what I saw in the m-e-p sources last week, maven-eclipse-plugin-test is created by the Plugin unit tests and then installed to a *test* repo local to the Eclipse project. Not sure why is your build seeing the -test version. Do you have maven-eclipse-plugin sources checked out and ran build on it? I believe the problem is in ProjectTool and it is munging real files instead of temp copies. Still investigating - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: continuum-webapp models
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 >
Re: continuum-webapp models
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
Re: [m2] build failure, Version: test ??? error
If i remember correct from what I saw in the m-e-p sources last week, maven-eclipse-plugin-test is created by the Plugin unit tests and then installed to a *test* repo local to the Eclipse project. Not sure why is your build seeing the -test version. Do you have maven-eclipse-plugin sources checked out and ran build on it? Rahul Barrie Treloar wrote: Manually hacking the jar to set the version correctly resolves the problem. Now to find out why the jar is being created incorrectly... Running mvn package will incorrectly create a "test" version for the real version jar. I just noticed that there are two jars in here: * maven-eclipse-plugin-2.3-INTERNAL-r485327-pMECLIPSE-206.jar * maven-eclipse-plugin-test.jar I expect the problem is that whatever is creating maven-eclipse-plugin-test.jar is stuffing up the creation of the proper versioned jar. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat failure
As a workaround - can you try moving the config from
continuum.xml to server.xml under global resoures (just like mentioned
on that thread). Pretty sure I have seen similar errors with JNDI
resource look ups in tomcat, but can't remember the solution off hand.
Cheers,
Rahul
Stephen Pietrowicz wrote:
I hadn't seen that thread. Thanks for the pointer to it.
I do get same message that the originator of that thread gets:
---
2006-12-12 14:20:31,590 [http-8080-Processor23] INFO
PlexusContainer- Loading on start [role]:
[org.apache.maven.continuum.Continuum]
2006-12-12 14:20:34,287 [http-8080-Processor23] ERROR
1-SNAPSHOT]- Exception sending context initialized
event to listener instance of class
org.codehaus.plexus.xwork.PlexusLifecycleListener
org.jpox.exceptions.ConnectionFactoryNotFoundException: Connection
Factory "java:comp/env/jdbc/continuum" not found
at
org.jpox.AbstractPersistenceManagerFactory.lookupDataSource(AbstractPersistenceManagerFactory.java:175)
[ rest of stack trace deleted]
but still haven't figured out the solution, even after adding the
continuum.xml file to the tomcat conf directory.
I'm not a Tomcat expert, so I think there are several other things I
need to do, but I can't tell what.
Here's what I did:
This morning I downloaded the bin of Tomcat-5.5.20, along with the
admin tools, and extracted everything. I added an account with
"manager and admin" to the tomcat-users.xml, and then I started Tomcat
with bin/startup.sh
For continuum, I did this:
mvn clean install
Back in Tomcat I went to the manager, and went down to the Deploy
section of the page and "uploaded" the war file from the
continuum-webapp directory to Tomcat.
Under applications on that page, it now shows
"/continuum-webapp-1.1-SNAPSHOT".
I click the start link on that line, and it gives me the message:
"FAIL - Application at context path /continuum-webapp-1.1-SNAPSHOT
could not be started".
and got the same error message in catalina.out as listed above.
The continuum.xml file I have is:
docBase="${catalina.base}/webapps/continuum-webapp-1.1-SNAPSHOT">
type="javax.sql.DataSource"
username="sa"
password=""
driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
url="jdbc:derby:target/database/users;create=true"
/>
type="javax.sql.DataSource"
username="sa"
password=""
driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
url="jdbc:derby:target/database/continuum;create=true"
/>
I'm missing something here, and I don't know what it is.
On Dec 11, 2006, at 3:04 PM, Rahul Thakur wrote:
Hi,
Are you seeing any other startup errors in the Tomcat logs/console?
BTW, have you seen this thread?
http://www.nabble.com/RE:-Deploy-trunk-on-tomcat-t2625572.html
Cheers,
Rahul
Stephen Pietrowicz wrote:
Hi,
I've checked out the latest version of Continuum from the source
tree, built it and tried to deploy it on Tomcat/5.5.17.
I received the message:
FAIL - Application at context path /continuum-webapp-1.1-SNAPSHOT
could not be started
Is there a workaround for this? I'm interested in 1.1 because of
the current Jira in 1.0.3 that prevents the "blame" from being
displayed on SVN checkouts. If there's a work-around for that in
1.0.3, I'd be able to use that.
Steve
Maven Eclipse code style preferences
Hi, Is anyone else noticing that Eclipse code style formatter is formatting Java sources differently? Is anyone able to verify that the codestyle preferences available from the site are sane or update if required. I downloaded the preferences just a couple of days ago. Can we also update the formatter preferences for javadocs to wrap to the next line after 80 chars? Thanks, Rahul
Re: Tomcat failure
Hi, Are you seeing any other startup errors in the Tomcat logs/console? BTW, have you seen this thread? http://www.nabble.com/RE:-Deploy-trunk-on-tomcat-t2625572.html Cheers, Rahul Stephen Pietrowicz wrote: Hi, I've checked out the latest version of Continuum from the source tree, built it and tried to deploy it on Tomcat/5.5.17. I received the message: FAIL - Application at context path /continuum-webapp-1.1-SNAPSHOT could not be started Is there a workaround for this? I'm interested in 1.1 because of the current Jira in 1.0.3 that prevents the "blame" from being displayed on SVN checkouts. If there's a work-around for that in 1.0.3, I'd be able to use that. Steve
Re: [vote] maven release process ( gpg / javadoc / site / source / remote-resources ) plugins.
+1 maven-gpg-plugin
+1 maven-javadoc-plugin
+1 maven-site-plugin
+1 maven-source-plugin
+1 maven-remote-resources-plugin
Rahul
- Original Message -
From: "Joakim Erdfelt" <[EMAIL PROTECTED]>
To: "Maven Developers List"
Sent: Monday, December 11, 2006 9:33 AM
Subject: [vote] maven release process ( gpg / javadoc / site / source /
remote-resources ) plugins.
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]
Re: Fwd: [vote] Archiva Logo
My vote is for: UR Cheers, Rahul Brett Porter wrote: FYI. You can vote over at archiva-dev@maven.apache.org - Brett Begin forwarded message: From: Brett Porter <[EMAIL PROTECTED]> Date: 13 November 2006 10:34:20 AM To: archiva-dev@maven.apache.org Subject: Re: [vote] Archiva Logo Reply-To: archiva-dev@maven.apache.org List-Id: Message-Id: <[EMAIL PROTECTED]> Currently, we have eliminated Top Left. We have 9 votes (60%) for lower left, and 6 for top right. In addition, we have more committers in the TR camp. That seems a bit close for now, so I'm going to look for more votes. On the other hand, all the TR's second preferences were for LL, whereas LL's second preferences were for LR, not TR. Please feel free to vote if you haven't. I'm going to get the logos put into the site so that we have a better frame of reference. Cheers, Brett On 08/11/2006, at 12:43 PM, Brett Porter wrote: Hi, There seemed to be no major objections to the logos presented, so I'll turn this into a formal vote. Please vote [1] for the one you would like and [2] for your second preference, if you have one, and so on. Ideally, there will be a clear majority of first preferences. The lowest scoring choice will be eliminated and their second preference used, and so on to determine the most popular. http://people.apache.org/~brett/archiva_logo.gif Vote will close in 72 hours. [ ] Top Left [ ] Top Right [ ] Lower Left [ ] Lower Right I will count the feedback from these people already: Raphael (1 - Lower Left), Wendell (1 - Lower Left), Milos (1 - Lower Left, 2 - Lower Right), Henri (1 - Lower Left), Natalie (1 - Top Right), Jesse (1 - Top Right), Edwin (1 Top Right), Nicolas (1 - Lower Left). If you want to change your vote, just respond again. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
so, what happened with the survey? :-) Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Sunday, November 26, 2006 2:54 PM Subject: Re: [discuss] Java 5 This would have zero impact on applications built with Maven. I'd been meaning to follow this up. Let me see what happened with the user survey... - Brett On 26/11/2006, at 12:49 PM, Brian E. Fox wrote: Our experience with our products is that not enough of the available portal and app servers support JDK 1.5 or our customers haven't yet upgraded. That unfortunately means we are stuck on 1.4 for the near future. I think many business customers are in the same predicament where we can't dictate the JDK required. If maven suddenly required Java 1.5, we would be in a serious bind and it would limit adoption of Maven 2.1. -Original Message- From: Rahul Thakur [mailto:[EMAIL PROTECTED] Sent: Saturday, November 25, 2006 7:55 PM To: Maven Developers List Subject: Re: [discuss] Java 5 This thread kinda died off silently Just wondering if there was a user survey about switching to Java 5.0? Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Sunday, July 09, 2006 6:09 AM Subject: Re: [discuss] Java 5 On 7 Jul 06, at 2:36 AM 7 Jul 06, Brett Porter wrote: Hi, I wanted to get thoughts on starting to require a Java 5 JVM to run stuff we build. We currently restrict to 1.4 across the board. I think before this can be done we need to make sure we're not making life difficult for people. It may be the case that most people don't have a problem using a 1.5 JDK in their environment but it might be an ideal time to use one of the online survey services to take a real poll. If the vast majority of users were not adversely affected by a move to 1.5 I would be fine with, as I'd like to use 1.5 where possible. But if it's not the case we probably should hold off on this requirement. Here's what I'm thinking: - MRM and Continuum should switch now. Stuff built there is rarely consumed elsewhere, and a Java 5 requirement outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? I'll likely propose a vote on the first point before the first/next releases of them unless there are reasons not to. Cheers, Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [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]
Re: Maven 2.0.4 Checkout tag
I think you need the tagged sources here: https://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.4/ Rahul - Original Message - From: "Peter Anning" <[EMAIL PROTECTED]> To: Sent: Monday, November 27, 2006 7:32 PM Subject: Maven 2.0.4 Checkout tag Hi, I am trying to build maven from source. I used the following svs command to get the stable 2.0.4 release but I got 2.0.5-SNAPSHOT instead? svn co https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x maven-2.0.4 Thanks Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
This thread kinda died off silently Just wondering if there was a user survey about switching to Java 5.0? Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Sunday, July 09, 2006 6:09 AM Subject: Re: [discuss] Java 5 On 7 Jul 06, at 2:36 AM 7 Jul 06, Brett Porter wrote: Hi, I wanted to get thoughts on starting to require a Java 5 JVM to run stuff we build. We currently restrict to 1.4 across the board. I think before this can be done we need to make sure we're not making life difficult for people. It may be the case that most people don't have a problem using a 1.5 JDK in their environment but it might be an ideal time to use one of the online survey services to take a real poll. If the vast majority of users were not adversely affected by a move to 1.5 I would be fine with, as I'd like to use 1.5 where possible. But if it's not the case we probably should hold off on this requirement. Here's what I'm thinking: - MRM and Continuum should switch now. Stuff built there is rarely consumed elsewhere, and a Java 5 requirement outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? I'll likely propose a vote on the first point before the first/next releases of them unless there are reasons not to. Cheers, Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [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]
webapp start up error
okies, I tried running the webapp this evening to muck around with Notifier validations further, but looks like something is broken with the webapp startup. I have attached the debug output below. Any ideas? I am guessing recent updates to application.xml may have caused this. Appreciate any help. Cheers, Rahul - 2006-11-09 19:36:39.171::WARN: failed [EMAIL PROTECTED]/,file:/E:/continuum/continuum-webapp/src/main/webapp/} 2006-11-09 19:36:39.171::WARN: failed [EMAIL PROTECTED] 2006-11-09 19:36:39.171::WARN: failed [EMAIL PROTECTED] 2006-11-09 19:36:40.078::INFO: Started SelectChannelConnector @ 0.0.0.0:9090 2006-11-09 19:36:40.078::WARN: failed [EMAIL PROTECTED] [INFO] Jetty server exiting. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failure Embedded error: org.codehaus.plexus.PlexusContainerException: Error initializaing container in org.codehaus.plexus.container.initialization.StartLoadOnStartCompo [EMAIL PROTECTED] org.codehaus.plexus.mailsender.javamail.JavamailMailSender [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failure at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:340) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:272) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:177) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:183) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: java.lang.RuntimeException: org.codehaus.plexus.PlexusContainerException: Error initializaing container in org.codehaus.plexus.container.initializatio [EMAIL PROTECTED] at org.codehaus.plexus.xwork.PlexusLifecycleListener.contextInitialized(PlexusLifecycleListener.java:65) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:450) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1129) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:420) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:457) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) at org.mortbay.jetty.Server.doStart(Server.java:210) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) at org.mortbay.jetty.plugin.Jetty6Plu
Re: build scheduling issues
I meant extending the notion that every Project or ProjectGroup added to a Schedule also has an order attached to it which may be user assigned or default. Rahul Thakur wrote: How about extending the notion of Schedule and allow the user to re-order builds in a schedule? In absence of any order, default to the order the Projects/ProjectGroups were added to the schedule. Rahul 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 we need to take all projects from all groups, sort them 17:15 if we don't have a cycle, it's ok and we build all 17:15 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
Re: build scheduling issues
How about extending the notion of Schedule and allow the user to re-order builds in a schedule? In absence of any order, default to the order the Projects/ProjectGroups were added to the schedule. Rahul 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 we need to take all projects from all groups, sort them 17:15 if we don't have a cycle, it's ok and we build all 17:15 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
Re: project group shortcuts
Yep, this would be a nice improvement to look forward to from a usability perspective! While I can imagine generating suggestions for GroupId values for new M1 and M2 projects being added, I am not sure how we could come up with something similar for Shell or Ant projects. Cheers, Rahul Jesse McConnell wrote: Ok, I am going to try this out I think, here is a laundry list of what would happen followed by the benefits. * the id on project group and project classes usage is deprecated and goes back to being internal to the store, nothing references to a project or a group by 0,1,2,3 etc anymore. * groupId on the project group class becomes the unique string by which you access a project group, it is currently kinda floating around usage wise as sometimes the groupId from the pom loaded up on m2 projects * projectId is added to Project and is the unique string by which you refer to a project in a project group * groupId and projectId would be restricted to [a-zA-Z0-9.-] with no spaces and are the short names to refer to these group and project objects on the UI layer and everywhere else in continuum * cascading effects throughout a large chunk of continuum as the integer projectId and the freeform strings for projectGroupName and integer projectGroupId are deprecated and converted to the short names. benefits: * UI layer will standardize on how to refer to project groups and projects in those groups, without passing around internal jdo store identifiers, free form text strings or even the combination of both of those in some cases (this is a failing of mine from the project group refactor I did, it made the UI work clunkier in referring to these things) * by treating m1/ant/shell/m2 projects the same in the UI it should alleviate a ton of oddball UI issues that are cropping up where groups are created, not created, not referred to correctly, names not being passed around between linked actions, etc * following a convention for naming your groups and projects across instances of continuum will make clustering a lot easier, group 7 on this instance isn't necessarily group 7 in that instance * specifying the string group Id that you will refer to that group by on the adding of the project will allow you to load up multiple instances of the same project (ex one instance on trunk and one on a branch) into the same instance of continuum (versions in the poms for m2 should lets these play together nicely), right now I think the projects from that second addition will just add into the same project group unless you rename the name in the pom you are loading * the unique string project Id can be the same for the same project across multiple usages of that project in different groups, letting you refer to them as [Doxia/DoxiaCore] and [Doxia1.2/DoxiaCore] * m1/shell/m2/ant project groups are referred to in the exact same way, and get their values from the same source, on the adding of the group and underlying projects * we can have a GroupNamingMapper and ProjectNamingMapper interface that can be configurable to be used in the automatic generation of the string groupId and projectId so this naming process can be automated by following a convention in the naming of the poms for m2 * the groupId and projectId string values can be edited at any time, letting the user load up the Doxia group and then later change it to the DoxiaTrunk group and then add in a DoxiaBranchFoo group I am sure there are other benefits, but these are the ones that keep pointing me in this direction. I just think that we really need to take a step like this to clean up a lot of messy interactions between the UI layer and continuum core and the confusing mishmash of webwork action linkages involving groups and projects. anyone have any thoughts on this? I am pretty sure I can have this all done in a couple of days of work and I really think it will help maintenance and future development. jesse On 10/30/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: 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
Re: Project Group Notifiers
Hi, Can we have an element like: true in the pom.xml where the notifiers are being setup defaulting it to 'false' if none is defined. A value of 'true' implies the notifier is a ProjectGroup notifier and all child modules inherit it, 'false' that the notifier is project level - or vice versa, whatever makes more sense. The motivation is to control the level of notifiers and also let Continuum to work it out if none was defined. Jesse - I know we talked about zero-config and more control - this should address both, I think :-) Cheers, Rahul Jesse McConnell wrote: I have been working at this problem off and on for a few days and have a bit of a stumbling block I would like a bit of feedback on.. build definitions where easier for this since they had no equivalent POM linkage...but thats a bit of an issue with the notifiers I am finding. My original assumption was that any notifiers declared in the pom that I am loading in as an m2 project would be initialized as a group notifier. This becomes a minor issue as the way things stand right now I'll have to pass annoying groupPom boolean status into parts of the loading mechanism that I really don't want to. But then I just got to thinking that this only addresses it part way. Basically I wanted to ask if people were comfortable with the following statement. notifiers defined in the pom being loaded in as the project group pom ( the one input into the Add M2 Project page) and the notifiers defined in the parents of that pom are all group lvl notifiers. any notifiers defined below that point will be attached as individual project notifiers. In the case of notifiers configured in poms that are the parents of sub-modules/projects (but are still children of the top lvl continuum project group pom) will be added to each of the child poms below that. an example might help P1 -> P2 P2 -> P3 P2 -> P4 P4 -> P5 P4 -> P6 for P1-6, if P2 where the pom loaded into continuum as the project group, then * notifiers in P1 and P2 are group notifiers * notifiers in P4 are added to P4,5,6 as project notifiers Would this work as a hard and fast rule for notifiers? jesse
Re: File locked error on Windows
I can say for sure for windows, not sure about other OSs. May be this ought be added to tests or if some cool users on cool macosx and other cooler OSs can test ;-) Cheers, Rahul Jesse McConnell wrote: this only affects windows users right? and the solution is general and doesn't mess up those really cool macosx users, correct? :) jesse On 10/18/06, Rahul Thakur <[EMAIL PROTECTED]> wrote: Hi, Just been talking to Jesse on this one and he reckons this should be logged on here. For a Continuum webapp running on Jetty (on Windows) - I noticed that editing any resources results in files getting locked after the first time they are saved. janb on #jetty helped with this reference: http://docs.codehaus.org/display/JETTY/Files+locked+on+Windows Though I have patched this locally here, I am wondering if use of memory mapped files should be disabled in Continuum trunk itself - thoughts? Cheers, Rahul
Re: contents of a 1.1 release
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 guess best to restructure code base now and add new features in for 1.1 than to impact a relatively larger number of users later on (assuming any breaking/incompatible changes). 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 :) I can commit hours over weekends and may odd hours here and there during weekdays. thoughts? should we open this out to the users list maybe? jesse Cheers, Rahul
Database intialization error
Hi, I have been noticing an intialization error with database whenever the Continuum webapp restarts. And then jetty freezes after encountering that error. And it is making it hard to make any sort of even minor changes to Continuum webapp resources (working on cleaning up some CSS styles for displaying error messages here) Any one else noticing this error? (I tried inlining the logs in an email earlier but too big and apache mail server doesn't like that) Cheers, Rahul
Re: Anyway to call a goal from a mojo?
Here is the snippet I was talking about: http://www.nabble.com/m2%3A-Delegating-to-other-Mojo-tf1695516.html#a4602520 I haven't used @execute, but if it does the job - thats neat! Cheers, Rahul - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Tuesday, September 05, 2006 4:57 AM Subject: Re: Anyway to call a goal from a mojo? Code samples are always nice :-) I did also run into '@execute goal=install' which appears to invoke the 'install' goal of my plugin before the goal will execute. This might work for my needs, though I'm not sure exactly how the execution configuration relates to mojo's invoked in this manner. Is this "feature" documented somewhere? --jason On Sep 3, 2006, at 8:47 PM, Rahul Thakur wrote: You can use MavenEmbedder to do this. Pretty sure there was some example code floating on the user@ or dev@ list. I wrote a delegate mojo a while ago that does something similar but don't have the code handy here, but I can dig later today if you are keen at looking at it. Cheers, Rahul Jason Dillon wrote: Is there any (easy) way to call a goal from a mojo? I've got a geronimo:install goal, that does some assembly unpacking, and a geronimo:start goal which starts up the server. geronimo:start really needs to call geronimo:install before it runs. Is there an easy way to do this? The only way I can think to share this code, is to add more abstract classes to hold the methods... but that gets messy fast. Any ideas? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anyway to call a goal from a mojo?
You can use MavenEmbedder to do this. Pretty sure there was some example code floating on the user@ or dev@ list. I wrote a delegate mojo a while ago that does something similar but don't have the code handy here, but I can dig later today if you are keen at looking at it. Cheers, Rahul Jason Dillon wrote: Is there any (easy) way to call a goal from a mojo? I've got a geronimo:install goal, that does some assembly unpacking, and a geronimo:start goal which starts up the server. geronimo:start really needs to call geronimo:install before it runs. Is there an easy way to do this? The only way I can think to share this code, is to add more abstract classes to hold the methods... but that gets messy fast. Any ideas? --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]
[m2 trunk] build test failures
Hey everyone, I am noticing quite a few IT test failures on the latest SVN snapshot from trunk, wondering if there are any refactorings/major changes taking place?? Here's the bunch that failed: 69/100 passed Failed tests: [it0099, it0092, it0089, it0088, it0087, it0086, it0077, it0073, it0071, it0068, it0067, it0064, it0062, it0051, it0049, it0041, it0035, it0034, it0030, it0029, it0021, it0020, it0018, it0013, it0009, it0008, it0007, it0005, it0004, it0003, it0002] I am on WinXP, JDK build 1.6.0-beta2-b76 and of course latest Maven 2.1-SNAPSHOT. Any one else noticing? Cheers, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1830) add a 'compiled on ' label when maven 2 is invoked with --version option
[ http://jira.codehaus.org/browse/MNG-1830?page=comments#action_60293 ] Rahul Thakur commented on MNG-1830: --- ping! Timestamp still doesn't show up. > add a 'compiled on ' label when maven 2 is invoked with --version > option > > > Key: MNG-1830 > URL: http://jira.codehaus.org/browse/MNG-1830 > Project: Maven 2 > Type: Improvement > Reporter: Rahul Thakur > Priority: Minor > > > It might be a good idea to append > 'compiled on ' > when maven2 is invoked with '--version' swtich/option, just like Ant does. > Can be helpful when compiling m2 locally 'n' times and need to ensure the m2 > installation was infact updated or when was it last updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MECLIPSE-71) eclipse:clean delets too much
[ http://jira.codehaus.org/browse/MECLIPSE-71?page=comments#action_60044 ] Rahul Thakur commented on MECLIPSE-71: -- I think the eclipse:clean goal should delete any artifacts the maven-eclipse-plugin generates (+1 on Fabrizio's comment above), so stuff under .settings should be cleaned up! Perhaps a better way to re-create the config/prefs under .settings would be to write a small Mojo specific to your dev environment that can take care of re-creating required files consistently rather than having to control and share them via SVN. One another solution could be to have an "ignore" list (comma-separated list of paths to resources under the project) that indicates to the eclipse:clean goal which resources to skip when running a 'clean' goal. What do others think? > eclipse:clean delets too much > - > > Key: MECLIPSE-71 > URL: http://jira.codehaus.org/browse/MECLIPSE-71 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Reinhard Poetz > > > If I call eclipse:clean, the complete ".settings" directory is deleted. In my > projects we share some Eclipse settings in our team by adding the .settings > directory to SVN. > This behaviour is unpractical for us as SVN gets confused by the missing > ./settings/.svn directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
