Re: Progress on MRM-463 - Metadata support
This seems to make sense (though the concurrency issues are
concerning, especially considering difficulty to test)
- Brett
On 31/08/2007, at 2:56 AM, Joakim Erdfelt wrote:
In the past 2 weeks I've made tremendous progress on the Metadata
issues within Archiva.
So far in trunk, the following changes have been made.
archiva-repository-layer:
[NEW] MetadataTools component that is responsible for the merging
and updating of inplace maven-metadata.xml files.
archiva-proxy:
[Update] DefaultProxyConnector now will ...
1) download requested maven-metadata.xml from *all* remote
repositories.
NOTE: must pass the pre-download policies first.
2) Save the downloaded maven-metadata.xml next to the maven-
metadata.xml that exists in the managed repository using a filename
format of maven-metadata-${proxyId}.xml (similar to how the maven 2
local repository works now).
3) After all of the downloads from all proxied repositories
complete, a MetadataTools.updateMetadata() call is issued to
perform an update on that maven-metadata.xml file.
4) Upon a completion of the MetadataTools.updateMetadata() with
no error, the maven-metadata.xml file in the managed repository is
returned to the requesting client.
What's left.
archiva-core-consumers:
[NEW] MetadataUpdaterConsumer - which runs as part of the
repository scanning process and updates all of the in-place maven-
metadata.xml files.
Alsø Alsø Wik: I'm only mildly worried about Concurrency issues
with this solution, as most calls for the maven-metadata.xml will
be caught by the pre-download policies, and updates to those files
will occur only on occasion.
Feel free to rip my logic to shreds and tell me what an idiot I am.
(it's really the only way I'll learn) :-)
- Joakim
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
Re: brief notes: upgrading 1.1-beta-1 to 1.1-beta-2
Without sql command: 1- with data-management: export the db java -Xmx512m -jar data-management-cli-1.1-beta-2-app.jar -buildsJdbcUrl jdbc:derby:path_continuum_old_db -mode EXPORT 2- start Continuum to create an empty db (with the good schema) 3- stop Continuum 4- import datas with data-management java -Xmx512m -jar data-management-cli-1.1-beta-2-app.jar -buildsJdbcUrl jdbc:derby:path_continuum_new_db -mode IMPORT 5- start Continuum data-management jar is available here: http://repo1.maven.org/maven2/org/apache/maven/continuum/data-management-cli/1.1-beta-2/data-management-cli-1.1-beta-2-app.jar Emmanuel Jesse McConnell a écrit : And this is what I did... I pulled the database someplace that I could run squirrelsql and ran the following sql statements to update the database, then I put the database back into place and started the updated version. -- ALTER TABLE INSTALLATION ADD installation_id integer not null default 0; ALTER TABLE PROFILE_ENVIRONMENTVARIABLES ADD installation_id_eid integer; alter table profiles add builder_installation_id_oid integer; alter table profiles add jdk_installation_id_oid integer; alter table projectdependency add modified_dependencies_id_own integer; alter table projectdependency add modified_dependencies_integer_idx integer; alter table profile_environmentvariables drop foreign key profile_envi2v_fk2; alter table profile_environmentvariables drop foreign key profile_envi2v_fk1; alter table profiles drop foreign key profiles_fk1; alter table profiles drop foreign key profiles_fk2; alter table installation drop primary key; alter table installation add primary key (installation_id); alter table profiles add CONSTRAINT profiles_fk1 foreign key (builder_installation_id_oid) references installation (installation_id); alter table profiles add CONSTRAINT profiles_fk2 foreign key (jdk_installation_id_oid) references installation (installation_id); alter table profile_environmentvariables add CONSTRAINT profile_envi2v_fk2 foreign key (installation_id_eid) references installation (installation_id); alter table profile_environmentvariables add CONSTRAINT profile_envi2v_fk1 foreign key (id_oid) references profiles (id); --- cheers! jesse On 8/17/07, Brett Porter [EMAIL PROTECTED] wrote: Here's what I did (this is a once off thing, though we really need to make sure changes are backwards compatible and can handle missing metadata in the future...) - run data-management from 1.1-beta-1 to export the build database (I had to build this from source) - edit the exported builds.xml to add installationId1/ installationId to each installation (using sequential numbers) - change name=... to installationId=... in each profile by replacing the name with the corresponding installation ID - comment out the environmentVariables profile since it would cause a duplicate PK (maybe a bug in the data management) - import the database again using data management from 1.1-beta-2. In case anyone needs it :) Cheers, Brett
Re: Splitting up the Installations form
+1 Wendy, can you file an issue? Olivier, do you want to work on it? Emmanuel Wendy Smoak a écrit : I think the form for adding a new Installation should be split up into one form for environment variables, and another for the Ant/Maven/JDK installations. The current web UI is confusing, we have a field marked as required when it usually isn't, necessitating a long field label to try to explain the situation. Thoughts?
RE: Splitting up the Installations form
Hi, Displaying the field (Environment Variable name bla bla ...) only when the user choose the type environnemt variable in the list box ? -- Olivier -Message d'origine- De : Wendy Smoak [mailto:[EMAIL PROTECTED] Envoyé : mardi 4 septembre 2007 05:07 À : continuum-dev@maven.apache.org Objet : Splitting up the Installations form I think the form for adding a new Installation should be split up into one form for environment variables, and another for the Ant/Maven/JDK installations. The current web UI is confusing, we have a field marked as required when it usually isn't, necessitating a long field label to try to explain the situation. Thoughts? -- Wendy This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. ** Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. **
Re: Splitting up the Installations form
Maybe like notifier screens, we can have a process an installation in two steps: screen1: choose the installation type (tool or environment variable) screen2(tool): version, path, parameters... screen2(env var): name, value Emmanuel LAMY Olivier a écrit : Hi, Displaying the field (Environment Variable name bla bla ...) only when the user choose the type environnemt variable in the list box ? -- Olivier -Message d'origine- De : Wendy Smoak [mailto:[EMAIL PROTECTED] Envoyé : mardi 4 septembre 2007 05:07 À : continuum-dev@maven.apache.org Objet : Splitting up the Installations form I think the form for adding a new Installation should be split up into one form for environment variables, and another for the Ant/Maven/JDK installations. The current web UI is confusing, we have a field marked as required when it usually isn't, necessitating a long field label to try to explain the situation. Thoughts? -- Wendy This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. ** Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. **
Re: Splitting up the Installations form
On 9/4/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: +1 Wendy, can you file an issue? Olivier, do you want to work on it? http://jira.codehaus.org/browse/CONTINUUM-1430 I'm not really a fan of the two-step process, but it's already being used for notifiers so we might as well be consistent. *However* in this case I don't think an environment variable qualifies as an installation, and they should really be split up completely. Or, call Installations something else. -- Wendy
[vote] Promote doxia-book and doxia-maven-plugin
Hi, Doxia is near to be released and I would like to promote doxia-book and doxia-maven-plugin. They will be moved to doxia/doxia/trunk/ Please vote [+1,0,-1], vote is open for 72 hrs. Thanks, Vincent
RE: [poll] Need for plugin packs / mixins for plugins
Wendy Smoak wrote on Monday, September 03, 2007 7:41 PM: On 9/1/07, Brett Porter [EMAIL PROTECTED] wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) B -- we're maintaining pluginManagement in a corporate parent pom and it's not that difficult. +1 I'd like to have more rules or help instead, like - enforce that no plugin is used, that is not declared in a pluginManagement section before - list all known plugins and their current versions - list all avalibale versions of a plugin - ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
Andrew Williams pisze: E) Specifying a a list of plugin versions in a pom snippet (better than plugin packs) is (as I see it) adding maintenance overhead that could become intrusive in some organisations. Why can we not just have a plugin (that maven suggests running if it seems missing version numbers) that updates your pom to specify the latest version of any plugins that are not currently stipulated. Running this on a parent pom in any organisation should eliminate the need for mixins or packs. +1 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
Brett Porter pisze: [X] (A) All plugin versions must be specified by the project or its parent hierarchy somewhere, at the cost of some verbosity (though we should look at ways to make this easier/smaller/etc per the current discussion) [ ] (B) Retain the current behaviour, but make using the enforcer a best practice to do the above, or some other control mechanism such as having the repository manager handle the available plugins [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) I support Jason's Dillo and Arik's Kfir opinions. At Apache Cocoon we have been suffering far too much from Maven's unpredictability in general. Last versions of Maven (2.0.6+) plus more knowledge about best practises in Maven made our builds controllable and very stable. The only remaining part are plug-in versions, exactly. It's worth to say that many of our brilliant members were so dissatisfied with broken builds driven by Maven that nobody had idea what's wrong that they started to claim that Cocoon is dying because of Maven. Many times, it was caused by our misuse or misunderstanding of Maven's philosophy but it was a Maven that allowed us to fall into these pitfalls. We are more clever now and fortunately enough, we are pretty satisfied with Maven today even if we have a lot of crap in our poms due to numerous bugs in Maven. My opinion is that Maven's community should be also more clever and should not allow people to screw their builds. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What can possibly go wrong with Maven
- invalid lifecycle phase (maybe same as bad CLI param, though you were talking about embedder too) - module specified is not found - POM doesn't exist for a goal that requires one - goal not found in a plugin (probably could list the ones that are) - parent POM missing (in both the repository + relative path) I can't think of anything else right now - might be best to crack open intelliJ and do find usages on Exception and it's child classes within the project files :) On 04/09/2007, at 9:57 AM, Jason van Zyl wrote: Hi, I'm trying to collect everything that can go wrong inside Maven so that it can be clearly pointed out to a user. We currently have a mechanism that analyzes stack traces, isn't localized, and is not very friendly for embedding as everything is couched in the form of console output. Here's the list that I came up with so far and I want to make to make a mechanism that says exactly what's wrong. Anyone have anything else? I'm not trying to consider everything that happens in plugins. I've identified almost all the places where those errors occur and I would like them to surface at the top in a form that is useful to embedding. As a by product it's easy to produce console output for the CLI. I don't care if the try/ catch is a mile long it's going to tell users exactly what happened when something goes wrong. I've pushed all console logging out of DefaultMaven and into the CLI. Moved the monitor into the core, but we still have console-centric logging in a bunch of the major components which I should be able to purge by the release of 2.1- alpha-1. Here's the list: - bad command line parameter - malformed settings - malformed POM - local repository not writable - remote repositories not available - artifact metadata missing - extension metadata missing - extension artifact missing - artifact metadata retrieval problem - version range violation - circular dependency - artifact missing - artifact retrieval exception - plugin metadata missing - plugin metadata retrieval problem - plugin artifact missing - plugin artifact retrieval problem - plugin dependency metadata missing - plugin dependency metadata retrieval problem - plugin configuration problem - plugin execution failure due to something that is know to possibly go wrong (like compilation failure) - plugin execution error due to something that is not expected to go wrong (the compiler executable missing) Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
Reading more responses, it seems like a lot of people want A so Maven can help people with their builds. In the long-run (post 2.1), I also like A, but we can't jump there overnight. Today I prefer B, but I am OK with A if we do the following: 1. Have a tag in the pom, which is also available on the command line, named unstable_build. Archetype should be modified to insert this tag and it should default to true (for now). 2. If unstable_build is true, we should throw a message at the beginning and end of the build that says Maven is running in UNSTABLE build mode. Go here http://maven.apache.org/FAQ/UnstableBuild to get rid of this message. and then we have a FAQ that talks about versioning things, how to lock things down, why its a good thing, etc. 3. If unstable_build is true and versions are unspecified, then Maven works like it does today. The tag unstable_build is specifically chosen to be somewhat offensive/negative and with immediately obvious meaning -- hopefully this is true for our international friends, too. No QE/QA group in the world would allow a self-declared unstable build pass their organization. But new users or expert users who don't want their versions locked down (yet) can still get into Maven and get things done without hassles. I appreciate the comments about helping people get their builds right etc and generally agree, but I don't think we can jump to this extreme overnight. So let's deprecate the idea of not specifying versions and then perhaps we can eliminate it (require all versions) in 2.2, 2.3, or 3.x. Wayne On 9/2/07, Wayne Fay [EMAIL PROTECTED] wrote: [X] (B) Retain the current behaviour, but make using the enforcer a best practice to do the above, or some other control mechanism such as having the repository manager handle the available plugins I am thinking about the new user experience and winning more converts. As such, I think the current behavior is best. Once they get using Maven more seriously (and in corporate environments that know what they're doing), I think adding the Enforcer configuration and locking versions down will come naturally. But *requiring* it seems excessive -- unless we're doing that ourselves somewhere, with plugin packs or similar, then I feel better about it. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What can possibly go wrong with Maven
- calling a goal that does not need a POM in the current dir in a multi-project root Examples: mvn install:install-file args mvn archetype:create args Maven walks down the complete project hierarchy ... Brett Porter wrote on Tuesday, September 04, 2007 10:15 AM: - invalid lifecycle phase (maybe same as bad CLI param, though you were talking about embedder too) - module specified is not found - POM doesn't exist for a goal that requires one - goal not found in a plugin (probably could list the ones that are) - parent POM missing (in both the repository + relative path) I can't think of anything else right now - might be best to crack open intelliJ and do find usages on Exception and it's child classes within the project files :) On 04/09/2007, at 9:57 AM, Jason van Zyl wrote: Hi, I'm trying to collect everything that can go wrong inside Maven so that it can be clearly pointed out to a user. We currently have a mechanism that analyzes stack traces, isn't localized, and is not very friendly for embedding as everything is couched in the form of console output. Here's the list that I came up with so far and I want to make to make a mechanism that says exactly what's wrong. Anyone have anything else? I'm not trying to consider everything that happens in plugins. I've identified almost all the places where those errors occur and I would like them to surface at the top in a form that is useful to embedding. As a by product it's easy to produce console output for the CLI. I don't care if the try/ catch is a mile long it's going to tell users exactly what happened when something goes wrong. I've pushed all console logging out of DefaultMaven and into the CLI. Moved the monitor into the core, but we still have console-centric logging in a bunch of the major components which I should be able to purge by the release of 2.1- alpha-1. Here's the list: - bad command line parameter - malformed settings - malformed POM - local repository not writable - remote repositories not available - artifact metadata missing - extension metadata missing - extension artifact missing - artifact metadata retrieval problem - version range violation - circular dependency - artifact missing - artifact retrieval exception - plugin metadata missing - plugin metadata retrieval problem - plugin artifact missing - plugin artifact retrieval problem - plugin dependency metadata missing - plugin dependency metadata retrieval problem - plugin configuration problem - plugin execution failure due to something that is know to possibly go wrong (like compilation failure) - plugin execution error due to something that is not expected to go wrong (the compiler executable missing) Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: aggregator issues and enforcer
On 04/09/2007, at 11:52 AM, Brian E. Fox wrote: I have a few problems I need to work through before the next enforcer release. First is that the enforce-once mojo declares @aggregator but still executes for all children. (MENFORCER-12) Is this a bug in maven or are aggregators still supposed to be inherited and executed? Sounds like a bug to me... is it better to just cache the result as the meaning of once instead of worrying about how many times Maven runs it? The next one is sorta related to the first. I've added some rules that require dependency resolution. Since there's currently no easy way to resolve dependencies inside the mojo besides @requiresDependencyResolution, I just set that. Unfortunately the combination of aggregator and dependencyResolution is broken in maven and causes all kinds of havoc (MNG-2277 / MENFORCER-11). One way I thought to work around this is to make another enforcer goal like enforce:dependencies and then allow the rules to declare they need dependencies resolved and then warn and skip if they are configured to execute inside the regular enforce-once goal. This workaround seems kinda lame but even fixing MNG-2277 in 2.0.8 means it's still broken for those with older versions which isn't good either. Suggestions? Yeah, unfortunately I think you might need to work around it... though having a dependencies goal does seem lame. Would changing the behaviour of enforce-once to not need the @aggregator be better? - 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: What can possibly go wrong with Maven
On 4 Sep 07, at 1:15 AM 4 Sep 07, Brett Porter wrote: - invalid lifecycle phase (maybe same as bad CLI param, though you were talking about embedder too) Yup, this is caught with some validation code I added the other day but it needs to filter up nicely. It doesn't currently. - module specified is not found - POM doesn't exist for a goal that requires one - goal not found in a plugin (probably could list the ones that are) - parent POM missing (in both the repository + relative path) I will add these to the list. I'm certain 99/100 we can tell users exactly what's wrong and no reason we can't do it in plain language. I can't think of anything else right now - might be best to crack open intelliJ and do find usages on Exception and it's child classes within the project files :) On 04/09/2007, at 9:57 AM, Jason van Zyl wrote: Hi, I'm trying to collect everything that can go wrong inside Maven so that it can be clearly pointed out to a user. We currently have a mechanism that analyzes stack traces, isn't localized, and is not very friendly for embedding as everything is couched in the form of console output. Here's the list that I came up with so far and I want to make to make a mechanism that says exactly what's wrong. Anyone have anything else? I'm not trying to consider everything that happens in plugins. I've identified almost all the places where those errors occur and I would like them to surface at the top in a form that is useful to embedding. As a by product it's easy to produce console output for the CLI. I don't care if the try/catch is a mile long it's going to tell users exactly what happened when something goes wrong. I've pushed all console logging out of DefaultMaven and into the CLI. Moved the monitor into the core, but we still have console-centric logging in a bunch of the major components which I should be able to purge by the release of 2.1-alpha-1. Here's the list: - bad command line parameter - malformed settings - malformed POM - local repository not writable - remote repositories not available - artifact metadata missing - extension metadata missing - extension artifact missing - artifact metadata retrieval problem - version range violation - circular dependency - artifact missing - artifact retrieval exception - plugin metadata missing - plugin metadata retrieval problem - plugin artifact missing - plugin artifact retrieval problem - plugin dependency metadata missing - plugin dependency metadata retrieval problem - plugin configuration problem - plugin execution failure due to something that is know to possibly go wrong (like compilation failure) - plugin execution error due to something that is not expected to go wrong (the compiler executable missing) Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What can possibly go wrong with Maven
On 04/09/2007, at 6:24 PM, Jörg Schaible wrote: - calling a goal that does not need a POM in the current dir in a multi-project root Examples: mvn install:install-file args mvn archetype:create args Maven walks down the complete project hierarchy ... But Maven can't tell the difference between doesn't need a POM (archetype, which can use it and add a module if it exists) and shouldn't use a POM (install-file), so this isn't an error condition. It's something the plugin developers need to take into account. - 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: Lining up maven-artifact for a release
Hi Jason, I'll try to find some time this afternoon to have a go at merging my branch into maven-artifact. It'd be good to get the code in before the branch gets stale. Cheers, Mark On 03/09/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, We need to collect all outstanding fixes done on the 2.0.x branch merged into the decoupled version and we need to collect all the filters that are floating around all over the place. I think the filters can be in a separate tree and we can decide what we want to shade in by default but we need to collect this before doing a release. Doxia is about to be released, and when maven-artifact is released we can release 2.1-alpha-1. Mark do you want to try and get your changes into the decouple maven- artifact? I will hunt around for filters and make some space in SVN for them. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lining up maven-artifact for a release
On 4 Sep 07, at 1:52 AM 4 Sep 07, Mark Hobson wrote: Hi Jason, I'll try to find some time this afternoon to have a go at merging my branch into maven-artifact. It'd be good to get the code in before the branch gets stale. Indeed, when I wake up I'll take a look. Tomorrow evening I'll try to integrate it into the daily build I'm doing for 2.1.x and see how that goes. Cheers, Mark On 03/09/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, We need to collect all outstanding fixes done on the 2.0.x branch merged into the decoupled version and we need to collect all the filters that are floating around all over the place. I think the filters can be in a separate tree and we can decide what we want to shade in by default but we need to collect this before doing a release. Doxia is about to be released, and when maven-artifact is released we can release 2.1-alpha-1. Mark do you want to try and get your changes into the decouple maven- artifact? I will hunt around for filters and make some space in SVN for them. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Decoupling of Maven Artifact
Forgot to add my 2c :) for the record - I'm in favour. Two things I want to ensure happen, though: - I'd like to see scope limited to just improving the API, packaging and usage (as was proposed) - many of the comments touch on how to change/improve/fix the resolution mechanism itself. That is a different proposal. - I would like to see changes done entirely within the artifact trunk in a self-contained way, and Maven updated as it stabilises - not a constant chasing of snapshots (or even alphas), especially with the troubles we've seen with the similar plexus changes recently. We should expect to see a stable, tested, documented release of artifact 3.0 as a result of this proposal well in advance of Maven 2.1. (added to the page as well) Cheers, Brett On 04/08/2007, at 1:17 AM, John Casey wrote: +1, I'll add my (few) comments to the page. -john On Aug 2, 2007, at 11:13 PM, Jason van Zyl wrote: Hi, I have put the text of the proposal here so that it doesn't get lost: http://docs.codehaus.org/display/MAVEN/Decoupling+of+Maven+Artifact But I would like to decouple the artifact handling code from Maven in an attempt to improve it and make it easier for people to use. This is also how I see making proposals work going forward. Put them in the wiki, bring it up here, if there is concern we can discuss it, otherwise after a reasonable period of time (3 days) the person who made the proposal can just do it if there is no conflict. So if you agree and don't have to comment if you don't want to. What's important is the proposal be visible (initial mailing list and wiki) and remain visible (the wiki in the proposals section). I also added a date to the proposal item so that you can see when it started. So we can cull stuff from the active list if it sits there forever without any ongoing effort. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with ejb deployment
Hi all I am trying to deploy ejb using maven and websphere application server? Can anybody please tell me which cargo plugin is required? I know there are cargo jboss and weblogic plugins available but does anybody know whether any Cargo Maven plugin is available for websphere? Also when I run the command mvn cargo:deploy I get the below error Internal error in the plugin manager executing goal 'org.codehaus.cargo:c argo-maven2-plugin:0.3.1:deploy': Unable to find the mojo ' org.codehaus.cargo:ca rgo-maven2-plugin:0.3.1:deploy' in the plugin ' org.codehaus.cargo:cargo-maven2-p lugin' Disclaimer: ' The contents of this electronic mail message are only binding upon Equens or its affiliates, if the contents of the message are accompanied by a lawfully recognized type of signature. The contents of this electronic mail message are priviliged and confidential and are intended only for use by the addressee. If you have received this electronic mail message by error, please notify the sender and delete the message without taking notices of its content, reproducing it and using it in any way.' Equens was founded by Interpay Nederland B.V. and Transaktionsinstitut für Zahlungsverkehrsdienstleistungen AG
Abolishing Extensions in 2.1
After trying to chase down a problem with extensions it became very clear to me that we have mixed concerns with extensions and it just makes the core crappy. The biggest offender are providers posing as extensions: wagon-webdav is not an extension, it is a dependency required by the deploy plugin. In the exact same way you would specify an SCM provider as dependency of the release plugin if you needed, say, ClearCase support. These are not general extensions they are specifically required by certain plugins and should be defined as such to scope their use. Dumping wagon-webdav into the core is not very bright considering it's use is limited to the deploy plugin. People have also used extensions to make available certain resources like checkstyle rules. Are these also not dependencies of a given plugin? Finally, the only things that in my opinion count as extensions are addition components that augment core functionality: artifact resolvers, version conflict resolvers, profile activator, project builders and the like. These should have an element like coreExtensions/ or something like it. Look at the extensions element and it begs the questions and extension to what exactly. For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What can possibly go wrong with Maven
Brett Porter wrote on Tuesday, September 04, 2007 10:31 AM: On 04/09/2007, at 6:24 PM, Jörg Schaible wrote: - calling a goal that does not need a POM in the current dir in a multi-project root Examples: mvn install:install-file args mvn archetype:create args Maven walks down the complete project hierarchy ... But Maven can't tell the difference between doesn't need a POM (archetype, which can use it and add a module if it exists) and shouldn't use a POM (install-file), so this isn't an error condition. It's something the plugin developers need to take into account. Yes, but has the Mojo any chance of telling this to Maven? I am not too familiar with the internals, but I assume that the evaluation of the POMs takes place before the goal is called. If the Mojo has already the possibility to supress the traversal of the modules, then I agree and it's a simple bug in the goal. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What can possibly go wrong with Maven
On 04/09/2007, at 7:40 PM, Jörg Schaible wrote: Brett Porter wrote on Tuesday, September 04, 2007 10:31 AM: On 04/09/2007, at 6:24 PM, Jörg Schaible wrote: - calling a goal that does not need a POM in the current dir in a multi-project root Examples: mvn install:install-file args mvn archetype:create args Maven walks down the complete project hierarchy ... But Maven can't tell the difference between doesn't need a POM (archetype, which can use it and add a module if it exists) and shouldn't use a POM (install-file), so this isn't an error condition. It's something the plugin developers need to take into account. Yes, but has the Mojo any chance of telling this to Maven? I am not too familiar with the internals, but I assume that the evaluation of the POMs takes place before the goal is called. If the Mojo has already the possibility to supress the traversal of the modules, then I agree and it's a simple bug in the goal. That's one of the things @aggregator is used for (though it has had problems as Brian showed). Anyway, I was just pointing out it wasn't related to the discussion at hand :) 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: Problem with ejb deployment
Hi, Hemant Ved schrieb: Hi all I am trying to deploy ejb using maven and websphere application server? Can anybody please tell me which cargo plugin is required? I know there are cargo jboss and weblogic plugins available but does anybody know whether any Cargo Maven plugin is available for websphere? Looking at the list of supported containers [1], it doesn't look like cargo is currently supporting websphere. When you search the cargo mailinglists you will find some discussions about implementing the support and a jira ticket with a patch [2]. Your chance of getting an authoritative answer will be much higher if you ask on the cargo mainling list though. Also when I run the command mvn cargo:deploy I get the below error Internal error in the plugin manager executing goal 'org.codehaus.cargo:c argo-maven2-plugin:0.3.1:deploy': Unable to find the mojo ' org.codehaus.cargo:ca rgo-maven2-plugin:0.3.1:deploy' in the plugin ' org.codehaus.cargo:cargo-maven2-p The error message says, that there is no 'deploy' goal available in the plugin. Have you tried with 'deployer-deploy'? Again, the cargo mailinglist would by more appropriate for this question. lugin' -Tim [1] http://cargo.codehaus.org/ [2] http://jira.codehaus.org/browse/CARGO-147 Disclaimer: ' The contents of this electronic mail message are only binding upon Equens or its affiliates, if the contents of the message are accompanied by a lawfully recognized type of signature. The contents of this electronic mail message are priviliged and confidential and are intended only for use by the addressee. If you have received this electronic mail message by error, please notify the sender and delete the message without taking notices of its content, reproducing it and using it in any way.' Equens was founded by Interpay Nederland B.V. and Transaktionsinstitut für Zahlungsverkehrsdienstleistungen AG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reg: problem using ant task
Hi
I am using Maven2 in my project to build the target.
I am trying to use ant task in my pom.xml using the maven-antrun-plugin
plugin
Following is the snippet of my pom.xml
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
configuration
tasks
property name=compile_classpath refid=maven.compile.classpath/
property name=runtime_classpath refid=maven.runtime.classpath/
property name=test_classpath refid=maven.test.classpath/
property name=plugin_classpath refid=maven.plugin.classpath/
echo message=compile classpath: ${compile_classpath}/
echo message=runtime classpath: ${runtime_classpath}/
echo message=test classpath: ${test_classpath}/
echo message=plugin classpath: ${plugin_classpath}/
/tasks
/configuration
goals
goalrun/goal
/goals
/executions
/plugin
/plugins
When I try to run my pom.xml, I am getting following error at the
Command line
D:\ossj\jsr091\troubleticket-1_2\workspace\spec\maven\maven-2.0.7\bin\m
vn
[INFO] Scanning for projects...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: unknown
POM Location: D:\ossj\jsr091\troubleticket-1_2\workspace\spec\pom.xml
Reason: Parse error reading POM. Reason: parser must be on START_TAG or
TEXT to
read text (position: START_TAG seen ...configurationtasks... @58:43)
for pr
oject unknown at D:\ossj\jsr091\troubleticket-1_2\workspace\spec\pom.xml
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Parse error reading
POM. Reaso
n: parser must be on START_TAG or TEXT to read text (position: START_TAG
seen ..
.configurationtasks... @58:43) for project unknown at
D:\ossj\jsr091\troubl
eticket-1_2\workspace\spec\pom.xml
at
org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
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.project.InvalidProjectModelException: Parse
error re
ading POM. Reason: parser must be on START_TAG or TEXT to read text
(position: S
TART_TAG seen ...configurationtasks... @58:43) for project unknown
at D:\os
sj\jsr091\troubleticket-1_2\workspace\spec\pom.xml
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(Default
MavenProjectBuilder.java:1422)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(Default
MavenProjectBuilder.java:1379)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi
leInternal(DefaultMavenProjectBuilder.java:477)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave
nProjectBuilder.java:200)
at
org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:553)
at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467)
at
org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364)
... 11 more
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException:
parser must
be on START_TAG or TEXT to read text (position: START_TAG seen
...configuratio
ntasks... @58:43)
at
org.codehaus.plexus.util.xml.pull.MXParser.nextText(MXParser.java:106
8)
at
org.apache.maven.model.io.xpp3.MavenXpp3Reader.parsePlugin(MavenXpp3R
eader.java:2905)
at
org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseBuild(MavenXpp3Re
ader.java:753)
at
org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Re
ader.java:2224)
at
org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.j
ava:4422)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(Default
MavenProjectBuilder.java:1418)
... 17 more
[INFO]
[INFO] Total time: 1 second
Re: What can possibly go wrong with Maven
- Classloader problems: often difficult to debug them when artifacts are coming from different transitive sources. Would be great to have a better way to display a trace of the dependency tree, without being swamped by all the non-dependency noise. Maybe a new debug flag (different from -X and -e) would help here. Jason van Zyl wrote: Hi, I'm trying to collect everything that can go wrong inside Maven so that it can be clearly pointed out to a user. We currently have a mechanism that analyzes stack traces, isn't localized, and is not very friendly for embedding as everything is couched in the form of console output. Here's the list that I came up with so far and I want to make to make a mechanism that says exactly what's wrong. Anyone have anything else? I'm not trying to consider everything that happens in plugins. I've identified almost all the places where those errors occur and I would like them to surface at the top in a form that is useful to embedding. As a by product it's easy to produce console output for the CLI. I don't care if the try/catch is a mile long it's going to tell users exactly what happened when something goes wrong. I've pushed all console logging out of DefaultMaven and into the CLI. Moved the monitor into the core, but we still have console-centric logging in a bunch of the major components which I should be able to purge by the release of 2.1-alpha-1. Here's the list: - bad command line parameter - malformed settings - malformed POM - local repository not writable - remote repositories not available - artifact metadata missing - extension metadata missing - extension artifact missing - artifact metadata retrieval problem - version range violation - circular dependency - artifact missing - artifact retrieval exception - plugin metadata missing - plugin metadata retrieval problem - plugin artifact missing - plugin artifact retrieval problem - plugin dependency metadata missing - plugin dependency metadata retrieval problem - plugin configuration problem - plugin execution failure due to something that is know to possibly go wrong (like compilation failure) - plugin execution error due to something that is not expected to go wrong (the compiler executable missing) Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with ejb deployment
Hi Which version of WebSphere is this? Hermod -Original Message- From: Hemant Ved [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 04, 2007 11:07 AM To: dev@maven.apache.org Cc: [EMAIL PROTECTED] Subject: Problem with ejb deployment Hi all I am trying to deploy ejb using maven and websphere application server? Can anybody please tell me which cargo plugin is required? I know there are cargo jboss and weblogic plugins available but does anybody know whether any Cargo Maven plugin is available for websphere? Also when I run the command mvn cargo:deploy I get the below error Internal error in the plugin manager executing goal 'org.codehaus.cargo:c argo-maven2-plugin:0.3.1:deploy': Unable to find the mojo ' org.codehaus.cargo:ca rgo-maven2-plugin:0.3.1:deploy' in the plugin ' org.codehaus.cargo:cargo-maven2-p lugin' Disclaimer: ' The contents of this electronic mail message are only binding upon Equens or its affiliates, if the contents of the message are accompanied by a lawfully recognized type of signature. The contents of this electronic mail message are priviliged and confidential and are intended only for use by the addressee. If you have received this electronic mail message by error, please notify the sender and delete the message without taking notices of its content, reproducing it and using it in any way.' Equens was founded by Interpay Nederland B.V. and Transaktionsinstitut für Zahlungsverkehrsdienstleistungen AG * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The upcoming doxia release depends upon PLXCOMP-80, need help applying patch
I always want to remove System.out.println! Thanks Dennis for this. Cheers, Vincent 2007/9/2, Dennis Lundberg [EMAIL PROTECTED]: Thanks Jason! Jason van Zyl wrote: Patched and released. You just need to wait for the sync. On 2 Sep 07, at 5:18 AM 2 Sep 07, Dennis Lundberg wrote: Hi I'm going through the last remaining issues for the upcoming release of doxia 1.0-alpha-9. One of these issues is http://jira.codehaus.org/browse/PLXCOMP-80 It has a patch attached and is dead simple. I'd be grateful if someone with karma at Plexus could apply the patch and propose a release of plexus-velocity-1.1.7. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Abolishing Extensions in 2.1
On 04/09/2007, at 7:34 PM, Jason van Zyl wrote: After trying to chase down a problem with extensions it became very clear to me that we have mixed concerns with extensions and it just makes the core crappy. The biggest offender are providers posing as extensions: wagon- webdav is not an extension, it is a dependency required by the deploy plugin. In the exact same way you would specify an SCM provider as dependency of the release plugin if you needed, say, ClearCase support. These are not general extensions they are specifically required by certain plugins and should be defined as such to scope their use. Dumping wagon-webdav into the core is not very bright considering it's use is limited to the deploy plugin. Agree - but currently the thing that uses those wagons is in the core I think (the artifact deployer) - so that would need to be separated into a dependency only used by the deploy plugin. The case is the same for wagon-ssh - though in that case it can be used to download so would need to be in the core. People have also used extensions to make available certain resources like checkstyle rules. Are these also not dependencies of a given plugin? Yeah, and that's definitely recommended - I think they've only ever wound up as extensions to work around bugs in the plugin dependencies. Finally, the only things that in my opinion count as extensions are addition components that augment core functionality: artifact resolvers, version conflict resolvers, profile activator, project builders and the like. These should have an element like coreExtensions/ or something like it. Look at the extensions element and it begs the questions and extension to what exactly. Agreed For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? I don't see a need to rush - for now, I would go with a deprecation on extensions / instead of dropping it. Once active collections are in place then there should be no more need for them since as I understand it you basically have nothing in the core then and just pull them in where they are needed for wagons and scm providers. So we could look at dropping them out in the next version. 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: Problem with ejb deployment
was6.0 On 9/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Which version of WebSphere is this? Hermod -Original Message- From: Hemant Ved [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 04, 2007 11:07 AM To: dev@maven.apache.org Cc: [EMAIL PROTECTED] Subject: Problem with ejb deployment Hi all I am trying to deploy ejb using maven and websphere application server? Can anybody please tell me which cargo plugin is required? I know there are cargo jboss and weblogic plugins available but does anybody know whether any Cargo Maven plugin is available for websphere? Also when I run the command mvn cargo:deploy I get the below error Internal error in the plugin manager executing goal 'org.codehaus.cargo:c argo-maven2-plugin:0.3.1:deploy': Unable to find the mojo ' org.codehaus.cargo:ca rgo-maven2-plugin:0.3.1:deploy' in the plugin ' org.codehaus.cargo:cargo-maven2-p lugin' Disclaimer: ' The contents of this electronic mail message are only binding upon Equens or its affiliates, if the contents of the message are accompanied by a lawfully recognized type of signature. The contents of this electronic mail message are priviliged and confidential and are intended only for use by the addressee. If you have received this electronic mail message by error, please notify the sender and delete the message without taking notices of its content, reproducing it and using it in any way.' Equens was founded by Interpay Nederland B.V. and Transaktionsinstitut für Zahlungsverkehrsdienstleistungen AG * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abolishing Extensions in 2.1
On Sep 4, 2007, at 5:34 AM, Jason van Zyl wrote: The biggest offender are providers posing as extensions: wagon- webdav is not an extension, it is a dependency required by the deploy plugin. In the exact same way you would specify an SCM provider as dependency of the release plugin if you needed, say, ClearCase support. These are not general extensions they are specifically required by certain plugins and should be defined as such to scope their use. Dumping wagon-webdav into the core is not very bright considering it's use is limited to the deploy plugin. This is an oversimplification. Wagons are also used in resolving artifacts, and while this is not a useful example WRT webdav, the ftp or scp wagons could easily be required for resolving dependencies...which is not a plugin task. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Re: [vote] Promote doxia-book and doxia-maven-plugin
+1, sounds like a great idea. -john On Sep 4, 2007, at 8:53 AM, Vincent Siveton wrote: Hi, Doxia is near to be released and I would like to promote doxia-book and doxia-maven-plugin. They will be moved to doxia/doxia/trunk/ Please vote [+1,0,-1], vote is open for 72 hrs. Thanks, Vincent --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
RE: Abolishing Extensions in 2.1
+1 -Original Message- SNIP For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Decoupling of Maven Artifact
On Sep 4, 2007, at 5:03 AM, Brett Porter wrote: - I would like to see changes done entirely within the artifact trunk in a self-contained way, and Maven updated as it stabilises - not a constant chasing of snapshots (or even alphas), especially with the troubles we've seen with the similar plexus changes recently. We should expect to see a stable, tested, documented release of artifact 3.0 as a result of this proposal well in advance of Maven 2.1. One interesting side-effect of this approach would be that we have no real clients for this library, at least not at first. This is dangerous in a way, because it leaves open the possibility that any APIs designed could be very cumbersome to use, and may not fulfill all of the requirements. In some ways, this is where maven-artifact* fell down in the first place, not having very many clients (we didn't have many plugins using maven-artifact extensively at the time, for instance)...not having a lot of use cases, we failed to provide easy access to POM and/or transitive dependency metadata for users of the library, forcing them to rebuild the associated MavenProject instances to get at this info...which in turn forced us into caching MavenProject and Artifact instances, to make this process less time consuming. It means we're going to have to be very diligent in harvesting use cases (and integration tests!) from the existing tools using maven- artifact before we make radical changes to the API...then, adapt these use cases as we refactor. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Re: [poll] Need for plugin packs / mixins for plugins
On Sep 1, 2007, at 10:53 PM, Brett Porter wrote: [ X] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) It seems to me that standardizing and releasing these snippets will be absolutely required in the very largest of environments, where development is highly distributed geographically, etc. etc. Also, in cases where it doesn't quite work to have only one plugin version specified one time in a single org pom for all projects everywhere for all time. IMO, we should pursue standardization of any boilerplate code, including standard additions to the POM...it doesn't preclude using snippets, for one thing. Also, it provides a lot more flexibility to do things like publish your own standardized (and maintained) suite of plugins as yet another open source offering for others to use. This will only serve to further stabilize Maven users' lives. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Re: [poll] Need for plugin packs / mixins for plugins
Don't forget that successive versions of some plugins may break backward compatibility and other such bad practices. Locking everyone in a large organization down to one version of such a plugin could be very limiting, since these things have to be phased in. Also, I don't think we can pretend that we have all of the requirements or use cases. I've heard some pretty convoluted approaches to managing this sort of data, and I don't have the understanding of the environment to make a judgement about whether they are doing things in an unnecessarily complex way, or even whether their approach can be changed (political environment can have a big impact here). I do think that mixins like this would be beneficial, and I'm really not at all convinced that it's a good idea to expand the scope of such mixins outside of the build element...so, basically plugin packs. To me, the term 'plugin pack' still needs some definition, so I'm willing to say that it's a good idea to provide this type of flexibility, and then help shape the concrete details a little bit to get at something reasonable. As far as many of the complexities involved in your questions at the beginning of your reply, we can use tooling to help with that sort of visibility too. Also, supporting plugin packs for the wider world doesn't preclude having internal policies against their use in organizations...maybe we'd do better to help people set rules about how Maven is allowed to be used? -john On Sep 2, 2007, at 11:30 AM, Jason van Zyl wrote: What are the real requirements? They are: 1) An easy way to get a set of stable plugins that work together 2) To easily see what versions are contained in this set 3) To easily change or augment what is in this set The current mechanism + toolings works. I know what's going to happen with plugin packs. Someone is going to want to change a version of a plugin they are using and How do I find out what versions of plugins am I using, How do I override what version of a plugin I'm using if it's specified in a plugin pack?, Does plugin management win if it's in a plugin pack?. I found a bug in the way plugin packs are processed and I can't get a plugin version I need, is there a work around?. How do I configure plugins that have been defined in the plugin pack. So people are going to have to end up redeclaring bits to get configuration and execution information locked down and then you end up with a terrible configuration management problem. A fully, and clear, literal way to define this is what is most practical. The questions below are also framed to bias the answers. For A, plugin packs are not the only solution. In very practical terms the total number of plugins is not that high. What people want to know is the stable set. The core processing required for the notion of a plugin pack will not be straight forward and it's not necessary and adds almost no value and I'm certain it will lead to greater complexity. Users want 1), 2), and 3). The current mechanism plus minimal tooling, or no tooling if people cut and paste (big deal) covers those requirements. Plugin packs cover 1) and then it becomes another nightmare to maintain. I am not in favor of plugin packs. On 1 Sep 07, at 7:53 PM 1 Sep 07, Brett Porter wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, 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] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Re: Gathering proposals for 2.1
+1 -j On Sep 3, 2007, at 9:20 PM, Brian E. Fox wrote: Now that we're getting close to a 2.1 alpha-1 release, it's time to really look closely at what is going to be included in the final release. In my opinion, it's been far too long between 2.0 and 2.1 (almost 2 years) and we need to get a stable release out sooner rather than later. I think that we should set a timeframe starting and ending soon (say starting tomorrow and going for 2 weeks) where we will collect proposals for 2.1 in the wiki. At the close of that timeframe, we review/discuss the proposals and select ones for 2.1 with an eye on keeping the release scope manageable. I think a deadline is really required to get people motivated to write up all their proposals. (I know I've got a few itches I need to propose to solve and this will get me moving too). A first step towards this will be creating a list of all the enhancements already made to 2.1 so the users won't propose things already solved. WDYT? --Brian --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Cleaning up 2.1.x JIRA
Hi, Jason took care of 2.1-alpha-1, and Brian has kicked off a proposal deadline, so that just leaves 2.1.x from the list I made earlier. So I'll start spending some time tomorrow trying to pick the top ~100 highest priority / most addressable / related issues from 2.1.x to keep, then propose to cut the rest for now. I'll also go through unscheduled. I know Deng already volunteered too - if she's still available and if anyone else is around it will be pretty short work. Any objections? Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: Lining up maven-artifact for a release
On 04/09/07, Jason van Zyl [EMAIL PROTECTED] wrote: Indeed, when I wake up I'll take a look. Tomorrow evening I'll try to integrate it into the daily build I'm doing for 2.1.x and see how that goes. Okay, I've branched maven-artifact and 2.1.x for MNG-612 and merged in the changes from the 2.0.x MNG-612 branch. See http://jira.codehaus.org/browse/MNG-612 comment for URLs and status. I haven't had time to test it out in 2.1.x, although that FIXME needs fixing first as detailed in the issue. When are you thinking of releasing maven-artifact? Could be worth trying to get 2.0.x to use it first in case it requires any changes. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Standards for Plugin Parameters
Hey, Blast from the past :) I had this flagged in my design issues folder (Thanks, mailtags!) and noticed we don't have it in the proposals. Full thread: http://mail-archives.apache.org/mod_mbox/maven-dev/ 200608.mbox/[EMAIL PROTECTED] Jason - is this another one to write up, or did this already get addressed in another way? I don't recall seeing it implemented, but I could be wrong. Cheers, Brett Begin forwarded message: From: Jason van Zyl [EMAIL PROTECTED] Date: 22 August 2006 9:40:53 AM To: Maven Developers List dev@maven.apache.org Subject: Standards for Plugin Parameters Reply-To: Maven Developers List dev@maven.apache.org List-Id: Maven Developers List dev.maven.apache.org Message-Id: [EMAIL PROTECTED] Hi, While working on MJAR-7, John and I discussed a possible standard for plugin parameters naming conventions. Which basically boil down to: field/property = noun|verbNoun expression= prefix.noun|verbNoun So for MJAR-7 we have field = forceCreation expression = jar.forceCreation So we are using camel case to avoid any potential interpolation problems, the noun|verbNoun form to use used within the plugin configuration, and the prefix.noun|verbNoun on the command line to prevent name collisions with other plugins. So that would be: plugin artifact-idmaven-jar-plugin/artifact-id configuration forceCreationfalse/forceCreation /configuration /plugin And on the command line it would be mvn -Djar.forceCreation=false I've seen all sorts of format for parameters as with everything the format is arbitrary but it would be good to have a standard guideline to follow. Anyone else have any thoughts? Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: [vote] bring shade-maven-plugin to apache
+1
Stéphane
On 9/3/07, Brian E. Fox [EMAIL PROTECTED] wrote:
The shade-maven-plugin is currently in the codehaus mojo sandbox. This
plugin is used by maven core to package the uberjar for distribution and
should be moved to the maven project.
Please vote {+1,0,-1], vote is open for 72 hrs.
+1
--
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abolishing Extensions in 2.1
What are the impacts of plugins with use extensions as a way to override the default build lifecycle? ie ( pde-maven-plugin, native-maven-plugin ) -D On 9/4/07, Brian E. Fox [EMAIL PROTECTED] wrote: +1 -Original Message- SNIP For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Abolishing Extensions in 2.1
On 4 Sep 07, at 11:55 AM 4 Sep 07, Dan Tran wrote: What are the impacts of plugins with use extensions as a way to override the default build lifecycle? ie ( pde-maven-plugin, native-maven- plugin ) There's another use case and that should also be made more clear, but ideally plugin metadata should say a contribution is being made and then we can act accordingly. So again another example of how extensions are generally confusing, I forgot about that use case. -D On 9/4/07, Brian E. Fox [EMAIL PROTECTED] wrote: +1 -Original Message- SNIP For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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 and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lining up maven-artifact for a release
On 4 Sep 07, at 8:37 AM 4 Sep 07, Mark Hobson wrote: On 04/09/07, Jason van Zyl [EMAIL PROTECTED] wrote: Indeed, when I wake up I'll take a look. Tomorrow evening I'll try to integrate it into the daily build I'm doing for 2.1.x and see how that goes. Okay, I've branched maven-artifact and 2.1.x for MNG-612 and merged in the changes from the 2.0.x MNG-612 branch. See http://jira.codehaus.org/browse/MNG-612 comment for URLs and status. I haven't had time to test it out in 2.1.x, although that FIXME needs fixing first as detailed in the issue. When are you thinking of releasing maven-artifact? Could be worth trying to get 2.0.x to use it first in case it requires any changes. Yes, we should try it to see if it's even feasible. I have a little Hudson grid I can flip it into to try it. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cleaning up 2.1.x JIRA
On 4 Sep 07, at 8:32 AM 4 Sep 07, Brett Porter wrote: Hi, Jason took care of 2.1-alpha-1, and Brian has kicked off a proposal deadline, so that just leaves 2.1.x from the list I made earlier. So I'll start spending some time tomorrow trying to pick the top ~100 highest priority / most addressable / related issues from 2.1.x to keep, then propose to cut the rest for now. I'll also go through unscheduled. I know Deng already volunteered too - if she's still available and if anyone else is around it will be pretty short work. Any objections? How are you going to decide priority before all the proposals are in? And I would pick features to implement not a 100 arbitrary issues. The workflow should be: - get all the proposals - select the proposals containing the features we want to implement - roadmap it across 2.1.x - then chop jira apart Handling bug fixes would be fine but anything related to features we can do until all the proposals are in, and then people have to commit to the proposals so that we know they will actually make it into the release as we expect. Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standards for Plugin Parameters
On 4 Sep 07, at 9:15 AM 4 Sep 07, Brett Porter wrote: Hey, Blast from the past :) I had this flagged in my design issues folder (Thanks, mailtags!) and noticed we don't have it in the proposals. Full thread: http://mail-archives.apache.org/mod_mbox/maven-dev/ 200608.mbox/[EMAIL PROTECTED] Jason - is this another one to write up, or did this already get addressed in another way? I don't recall seeing it implemented, but I could be wrong. As Brian pointed out let's get everyone to push in everything, the cut off date the Friday after next. Cheers, Brett Begin forwarded message: From: Jason van Zyl [EMAIL PROTECTED] Date: 22 August 2006 9:40:53 AM To: Maven Developers List dev@maven.apache.org Subject: Standards for Plugin Parameters Reply-To: Maven Developers List dev@maven.apache.org List-Id: Maven Developers List dev.maven.apache.org Message-Id: [EMAIL PROTECTED] Hi, While working on MJAR-7, John and I discussed a possible standard for plugin parameters naming conventions. Which basically boil down to: field/property = noun|verbNoun expression= prefix.noun|verbNoun So for MJAR-7 we have field = forceCreation expression = jar.forceCreation So we are using camel case to avoid any potential interpolation problems, the noun|verbNoun form to use used within the plugin configuration, and the prefix.noun|verbNoun on the command line to prevent name collisions with other plugins. So that would be: plugin artifact-idmaven-jar-plugin/artifact-id configuration forceCreationfalse/forceCreation /configuration /plugin And on the command line it would be mvn -Djar.forceCreation=false I've seen all sorts of format for parameters as with everything the format is arbitrary but it would be good to have a standard guideline to follow. Anyone else have any thoughts? Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Decoupling of Maven Artifact
On 4 Sep 07, at 2:03 AM 4 Sep 07, Brett Porter wrote: Forgot to add my 2c :) for the record - I'm in favour. Two things I want to ensure happen, though: - I'd like to see scope limited to just improving the API, packaging and usage (as was proposed) - many of the comments touch on how to change/improve/fix the resolution mechanism itself. That is a different proposal. That's all that's happened thus far. The required refactoring is another proposal. As far as general improvements like making the core not fail-fast is a general improvement in behavior regardless of any other internal changes. - I would like to see changes done entirely within the artifact trunk in a self-contained way, and Maven updated as it stabilises - not a constant chasing of snapshots (or even alphas), You can see whatever you like if you do the work. Alphas are perfectly fine in something that is alpha. As 2.1 becomes beta then we are feature complete and the consumption of snapshots or alphas stop as a part of that. Work that I plan in 2.1 will require changes in Maven Artifact. Arbitrarily not allowing alphas while something is itself in alpha is not reasonable. For betas and above that's a perfect sane tact. especially with the troubles we've seen with the similar plexus changes recently. We should expect to see a stable, tested, documented release of artifact 3.0 as a result of this proposal well in advance of Maven 2.1. It's alpha, that's life. I'm fine with the policy of releases post beta but things are going to change before that. Maven is a driver for the changes, I can't know everything up front so alphas will be used I'm sure. What really matters? What really matters in maven-artifact is that we retain backward compatibility so that we don't screw anyone. We also need to improve the tests in maven-artifact as there isn't much there and given these two things we can move forward safely. If we manage to get maven- artifact to work in 2.0.x then I believe we will be reasonably sure everything works if all the tests and ITs work correctly. (added to the page as well) Cheers, Brett On 04/08/2007, at 1:17 AM, John Casey wrote: +1, I'll add my (few) comments to the page. -john On Aug 2, 2007, at 11:13 PM, Jason van Zyl wrote: Hi, I have put the text of the proposal here so that it doesn't get lost: http://docs.codehaus.org/display/MAVEN/Decoupling+of+Maven+Artifact But I would like to decouple the artifact handling code from Maven in an attempt to improve it and make it easier for people to use. This is also how I see making proposals work going forward. Put them in the wiki, bring it up here, if there is concern we can discuss it, otherwise after a reasonable period of time (3 days) the person who made the proposal can just do it if there is no conflict. So if you agree and don't have to comment if you don't want to. What's important is the proposal be visible (initial mailing list and wiki) and remain visible (the wiki in the proposals section). I also added a date to the proposal item so that you can see when it started. So we can cull stuff from the active list if it sits there forever without any ongoing effort. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Gathering proposals for 2.1
I'll email the user list. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 04, 2007 5:41 AM To: Maven Developers List Subject: Re: Gathering proposals for 2.1 On 3 Sep 07, at 6:30 PM 3 Sep 07, Brian E. Fox wrote: I'm leaning that way as well. However, I'm not suggesting we take many (if any) of them but we should at least see what else might be out there...could be some killer feature we haven't thought of yet or a few simple changes that would make everyone's life easier. If nothing else, it provides the motivation now to get some proposals started for 2.2. I think that's good, it's really just a final call proposals after which you have to wait until 2.2. I agree that sooner is better then later. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, September 03, 2007 9:27 PM To: Maven Developers List Subject: Re: Gathering proposals for 2.1 On 04/09/2007, at 11:20 AM, Brian E. Fox wrote: WDYT? +Integer.MAX_VALUE I've got all the ones in that I care about, and my previous mail highlights the ones I think we should do. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cleaning up 2.1.x JIRA
On 05/09/2007, at 5:29 AM, Jason van Zyl wrote: How are you going to decide priority before all the proposals are in? And I would pick features to implement not a 100 arbitrary issues. New features account for about 10-15%, and improvements about 25% (I'm just guessing these from a pie chart). In unscheduled, it's a very small % of new features and about 25% improvements. So I think we can identify what are truly new features and apply the following: - if it is small or related to other things, it stays - if it is a big thing without a proposal, we can suggest they write one But mostly focus on cleaning up other than that.. Handling bug fixes would be fine but anything related to features we can do until all the proposals are in, and then people have to commit to the proposals so that we know they will actually make it into the release as we expect. Yep, no disagreement there. - 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: Standards for Plugin Parameters
On 05/09/2007, at 5:30 AM, Jason van Zyl wrote: On 4 Sep 07, at 9:15 AM 4 Sep 07, Brett Porter wrote: Hey, Blast from the past :) I had this flagged in my design issues folder (Thanks, mailtags!) and noticed we don't have it in the proposals. Full thread: http://mail-archives.apache.org/mod_mbox/maven-dev/ 200608.mbox/[EMAIL PROTECTED] Jason - is this another one to write up, or did this already get addressed in another way? I don't recall seeing it implemented, but I could be wrong. As Brian pointed out let's get everyone to push in everything, the cut off date the Friday after next. Yep... that's why I brought it up. Did you want to write it up? - Brett Cheers, Brett Begin forwarded message: From: Jason van Zyl [EMAIL PROTECTED] Date: 22 August 2006 9:40:53 AM To: Maven Developers List dev@maven.apache.org Subject: Standards for Plugin Parameters Reply-To: Maven Developers List dev@maven.apache.org List-Id: Maven Developers List dev.maven.apache.org Message-Id: [EMAIL PROTECTED] Hi, While working on MJAR-7, John and I discussed a possible standard for plugin parameters naming conventions. Which basically boil down to: field/property = noun|verbNoun expression= prefix.noun|verbNoun So for MJAR-7 we have field = forceCreation expression = jar.forceCreation So we are using camel case to avoid any potential interpolation problems, the noun|verbNoun form to use used within the plugin configuration, and the prefix.noun|verbNoun on the command line to prevent name collisions with other plugins. So that would be: plugin artifact-idmaven-jar-plugin/artifact-id configuration forceCreationfalse/forceCreation /configuration /plugin And on the command line it would be mvn -Djar.forceCreation=false I've seen all sorts of format for parameters as with everything the format is arbitrary but it would be good to have a standard guideline to follow. Anyone else have any thoughts? Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Problem with ejb deployment
You should not be sending these emails to Maven Dev list. This has nothing to do with the development of Maven software. Instead you should be sending these emails to the Maven Users list: [EMAIL PROTECTED] See more info: http://maven.apache.org/mail-lists.html Wayne On 9/4/07, Hemant Ved [EMAIL PROTECTED] wrote: was6.0 On 9/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Which version of WebSphere is this? Hermod -Original Message- From: Hemant Ved [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 04, 2007 11:07 AM To: dev@maven.apache.org Cc: [EMAIL PROTECTED] Subject: Problem with ejb deployment Hi all I am trying to deploy ejb using maven and websphere application server? Can anybody please tell me which cargo plugin is required? I know there are cargo jboss and weblogic plugins available but does anybody know whether any Cargo Maven plugin is available for websphere? Also when I run the command mvn cargo:deploy I get the below error Internal error in the plugin manager executing goal 'org.codehaus.cargo:c argo-maven2-plugin:0.3.1:deploy': Unable to find the mojo ' org.codehaus.cargo:ca rgo-maven2-plugin:0.3.1:deploy' in the plugin ' org.codehaus.cargo:cargo-maven2-p lugin' Disclaimer: ' The contents of this electronic mail message are only binding upon Equens or its affiliates, if the contents of the message are accompanied by a lawfully recognized type of signature. The contents of this electronic mail message are priviliged and confidential and are intended only for use by the addressee. If you have received this electronic mail message by error, please notify the sender and delete the message without taking notices of its content, reproducing it and using it in any way.' Equens was founded by Interpay Nederland B.V. and Transaktionsinstitut für Zahlungsverkehrsdienstleistungen AG * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - 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]
Call for 2.1 Proposals
As we are approaching an alpha release of 2.1, the Maven Team would like to make a final call for proposals. The cutoff date for new proposals will be Friday 9/21. During this time, we will review and discuss new proposals and make a final cut at scheduling the 2.1 release. The current aim is to keep the number of newly included proposals small so that we can get a release out sooner than later. Proposals that are accepted but not scheduled for 2.1.0 will be tentatively scheduled for 2.1.x or 2.2 If you have an idea you would like evaluated, please create a new wiki page here: (for users) http://docs.codehaus.org/display/MAVENUSER/User+Proposals or (for developers) http://docs.codehaus.org/display/MAVEN/All+Proposals --The Maven Team
[proposal] Make like reactor build mode
http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode Make like build behavior mode Maven currently has a top down build approach where you start at the top of a reactor and build all children. One of the most common requests I get from my developers is an easy way to build certain artifacts from the bottom up. Often times a build, especially large ones, will contain many modules needed for a full build, but are actually made up of pockets of interdependencies. It's not always possible to logically group these all together with a common parent to enable easily building a subtree. For example, you may have a project comprised of services, ui's and packages: +---packages | +---a-package | +---b-package | \---c-package +---services | +---a-service | +---b-service | \---c-service \---ui +---a-ui +---b-ui \---c-ui The packages inherit from the package parent, etc. Assume that A-package depends on a-service b-service and a-ui In Maven, there is currently no easy way to make a change to a-service and build it and the package at once. This can be controlled to some extent with modules in profiles, but this quickly becomes unwieldy and doesn't support the granularity needed. Out of Scope It is out of scope for this proposal to determine if a project actually needs to be rebuilt based on the contents. (ie checking if anything has actually changed) This is simply intended to be an extension to the reactor behavior in choosing which projects should be included in the reactor. Proposed Solution The ideal use case for this issue is: 1. Developer makes change to code in a-service 2. Developer goes to a-package and executes mvn -A install (-A for all) 3. Maven walks up the parent tree to see how far up the source goes. Then any dependencies in the graph that are found in the contained source on disk are ordered and built. Everything else is ignored in the build. Alternate Use Case: 2. Instead of going to a-package and executing mvn, the developer goes to the top level parent and executes mvn -Aa-package (in this case defining the module that should be considered for dependency graphing) 3. Maven builds the graph and builds what is needed. This use case isn't ideal but is probably easier to implement since the top level parent doesn't need to be located and everything to be built is included in the subtree.
[vote] Mauro Talevi committer access
Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1
Re: [vote] Mauro Talevi committer access
+1 On 05/09/2007, at 11:35 AM, Brian E. Fox wrote: Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1 -- 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: What can possibly go wrong with Maven
Component not found Missing goal in plugin (probably the wrong version) -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, September 03, 2007 7:58 PM To: Maven Developers List Subject: What can possibly go wrong with Maven Hi, I'm trying to collect everything that can go wrong inside Maven so that it can be clearly pointed out to a user. We currently have a mechanism that analyzes stack traces, isn't localized, and is not very friendly for embedding as everything is couched in the form of console output. Here's the list that I came up with so far and I want to make to make a mechanism that says exactly what's wrong. Anyone have anything else? I'm not trying to consider everything that happens in plugins. I've identified almost all the places where those errors occur and I would like them to surface at the top in a form that is useful to embedding. As a by product it's easy to produce console output for the CLI. I don't care if the try/catch is a mile long it's going to tell users exactly what happened when something goes wrong. I've pushed all console logging out of DefaultMaven and into the CLI. Moved the monitor into the core, but we still have console-centric logging in a bunch of the major components which I should be able to purge by the release of 2.1-alpha-1. Here's the list: - bad command line parameter - malformed settings - malformed POM - local repository not writable - remote repositories not available - artifact metadata missing - extension metadata missing - extension artifact missing - artifact metadata retrieval problem - version range violation - circular dependency - artifact missing - artifact retrieval exception - plugin metadata missing - plugin metadata retrieval problem - plugin artifact missing - plugin artifact retrieval problem - plugin dependency metadata missing - plugin dependency metadata retrieval problem - plugin configuration problem - plugin execution failure due to something that is know to possibly go wrong (like compilation failure) - plugin execution error due to something that is not expected to go wrong (the compiler executable missing) Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Mauro Talevi committer access
+1 Mauro is one of the most rigourous, dedicated and respectful developers I know. We would definitely be a better team with Mauro here. On 4 Sep 07, at 6:35 PM 4 Sep 07, Brian E. Fox wrote: Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1 Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Mauro Talevi committer access
+1 Arnaud On 05/09/07, Jason van Zyl [EMAIL PROTECTED] wrote: +1 Mauro is one of the most rigourous, dedicated and respectful developers I know. We would definitely be a better team with Mauro here. On 4 Sep 07, at 6:35 PM 4 Sep 07, Brian E. Fox wrote: Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1 Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Merging maven-plugin-api and maven-plugin-descriptor in trunk
Hi, I would like to make a single module for plugin execution and this is the first step. The motivator is being able to isolate a version of a plugin apis runtime. These modules do not vary independently in practice and they are not useful separately. I really would like people to look at the top-level source tree and easily see the key moving parts. Any objections? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] Mauro Talevi committer access
+1 -- Olivier -Message d'origine- De : Brian E. Fox [mailto:[EMAIL PROTECTED] Envoyé : mercredi 5 septembre 2007 03:35 À : Maven Developers List Objet : [vote] Mauro Talevi committer access Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1 This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. -- Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
