Re: Preparing for continuum-1.1-alpha-1
I think we shouldn't worry about making these actually releases cut with the maven-release-plugin. I say we just make a build and get it available for download. Also tag the continuum trunk accordingly. Then we ought to try to release a new alpha every few weeks until we have the alpha-# issues converging towards 0. Why not? Using the Maven plugin is generally easier than doing it by hand. Only issue that comes to mind are snapshots dependencies. having to resolve the snapshot dependencies are precisely the reason I didn't want to mess with the maven release plugin for this. I would have to release a new plexus-security and probably a couple of other little higgly piggly bits. I think we can get by with the timestamped SNAPSHOT dependencies for these things, means we can release alpha's more frequently as well since we don't have to deal with micro-releasing the dependencies each time. Seems like a good pick, but I have a couple of comments: CONTINUUM-253: why? can't it be done after the release? it can, it is just done partially in a couple of places and I thought it might be nice to have that all collated together, but yes..it can be pushed a bit CONTINUUM-827: sounds to me like this is something that can take a while, is it worth waiting for? Remember that the target for the next alpha should be within a month. fine by me :) What is the time estimate on completing all of the issues? I want to see this pushed this week and then every couple of weeks from here on out. jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
CLOB is supported by most of the databases, and Oracle is the only one with a particular API rather than plain JDBC Quoting Brett Porter [EMAIL PROTECTED]: Isn't Oracle the only database to offer a CLOB? I think writing it to a file in the build results directory like the other output makes perfect sense. Unless we are planning to search them, but then maybe lucene is a better choice anyway. Hmm, indexed and correlated build failures. I like that idea. Shiny. / me loses focus. - Brett On 12/03/2007, at 2:09 AM, Trygve Laugstøl wrote: Jesse McConnell wrote: sounds good to me, imo either trunc it or maybe switch the model over to a clob for that in the db... I tried to make it a CLOB once but couldn't get it to work because of some JPOX issues IIRC so for alpha-1 just chop the exception and/ or write it to a separate file and put the ideal solution into a later alpha. Keep moving! -- Trygve jesse On 3/9/07, Stephane Nicoll [EMAIL PROTECTED] wrote: On 3/9/07, Jesse McConnell [EMAIL PROTECTED] wrote: I have gone through jira issues there were assigned to 1.1 and spread things out a bit. here is my criteria I used in separating out the issues: 1.1-alpha-1 - issues that need to be addressed asap before we pull any kinda alpha Not because I opened this but I think CONTINUUM-1194 should be fixed. I'll try to provide a patch this sunday for this. As a summary, if an error occurs and the stacktrace is higher than 8000 chars: * The build is stuck in Build In Progress * No notification is triggered (an error has occured?!) Thanks, Stéphane 1.1-alpha-2 - higher importance issues and ones generally related to xml-rpc 1.1-alpha-# - issues that probably ought to be resolved in the alpha releases Future - stuff that probably ain't going to get done any day soon the idea being that we can make new sequential release issues off of the 1.1-alpha-# release tag until we are done with alpha releases. I think once 1.1-alpha-1 is released then we can go through 1.1- alpha-2 and decide what should be done, make a new release called 1.1- alpha-3 and bulk move issues that aren't going to be addressed then (like maybe all the xml-rpc issues) I think we shouldn't worry about making these actually releases cut with the maven-release-plugin. I say we just make a build and get it available for download. Also tag the continuum trunk accordingly. Then we ought to try to release a new alpha every few weeks until we have the alpha-# issues converging towards 0. When we actually get to beta/rc releases then we can cut actual releases. Now about my allocation of issues, its not gospel! If you disagree with any of my assigning of fix versions then just fix it yourself (the version, or better yet the bug). At the time of this writing I have the 1.1-alpha-1 release down to a modest 8 issues with a few of those questionable and/or waiting for a bit of feedback. I have yet to go through the 200 or so unfiled issues though so that might go up a bit, I'll do that now. thoughts? jesse On 3/7/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: We don't need it the migration tool now. We'll can see to it when we'll release a first beta on rc. Emmanuel Brett Porter a écrit : On 07/03/2007, at 9:52 AM, Jesse McConnell wrote: Ok, well the little poll thread I made seemed to be strongly in favor of getting things pulled together to start getting alpha releases out of continuum. So with that in mind here is a list of a few things that we need to get in order for an alpha release that I shamelessly started base on bretts comments - properly mark up the model as it was for 1.0.3 release - add methods to continuum-data-management to utilise that and then make any necessary transformations (c-d-m will do the basic 1-to-1 conversions) - probably write a little CLI to fire it off. - vet jira for a 1.1 alpha 1 release version and maybe schedule out a couple of alpha-# releases. I think I'll start in on the data management bit now since that seems like the biggest hurdle. I am not convinced we really need to worry about a continuum 1.0.3 - continuum 1.1 migration ability...its not a difficult thing to get projects loaded back up into continuum...but we'll see I guess. It is a pain, but having said that we could potentially add it in a later milestone. I wouldn't want a final version without it. anyone have anything to add? jesse --jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
ok, I'll plow through the rest of the uncategorized issues now :) jesse On 3/12/07, Thierry Lach [EMAIL PROTECTED] wrote: I'd like to see the JBoss integration http://jira.codehaus.org/browse/CONTINUUM-1167 added somewhere in the alpha process. On 3/12/07, Erik Bengtson [EMAIL PROTECTED] wrote: CLOB is supported by most of the databases, and Oracle is the only one with a particular API rather than plain JDBC Quoting Brett Porter [EMAIL PROTECTED]: Isn't Oracle the only database to offer a CLOB? I think writing it to a file in the build results directory like the other output makes perfect sense. Unless we are planning to search them, but then maybe lucene is a better choice anyway. Hmm, indexed and correlated build failures. I like that idea. Shiny. / me loses focus. - Brett On 12/03/2007, at 2:09 AM, Trygve Laugstøl wrote: Jesse McConnell wrote: sounds good to me, imo either trunc it or maybe switch the model over to a clob for that in the db... I tried to make it a CLOB once but couldn't get it to work because of some JPOX issues IIRC so for alpha-1 just chop the exception and/ or write it to a separate file and put the ideal solution into a later alpha. Keep moving! -- Trygve jesse On 3/9/07, Stephane Nicoll [EMAIL PROTECTED] wrote: On 3/9/07, Jesse McConnell [EMAIL PROTECTED] wrote: I have gone through jira issues there were assigned to 1.1 and spread things out a bit. here is my criteria I used in separating out the issues: 1.1-alpha-1 - issues that need to be addressed asap before we pull any kinda alpha Not because I opened this but I think CONTINUUM-1194 should be fixed. I'll try to provide a patch this sunday for this. As a summary, if an error occurs and the stacktrace is higher than 8000 chars: * The build is stuck in Build In Progress * No notification is triggered (an error has occured?!) Thanks, Stéphane 1.1-alpha-2 - higher importance issues and ones generally related to xml-rpc 1.1-alpha-# - issues that probably ought to be resolved in the alpha releases Future - stuff that probably ain't going to get done any day soon the idea being that we can make new sequential release issues off of the 1.1-alpha-# release tag until we are done with alpha releases. I think once 1.1-alpha-1 is released then we can go through 1.1- alpha-2 and decide what should be done, make a new release called 1.1- alpha-3 and bulk move issues that aren't going to be addressed then (like maybe all the xml-rpc issues) I think we shouldn't worry about making these actually releases cut with the maven-release-plugin. I say we just make a build and get it available for download. Also tag the continuum trunk accordingly. Then we ought to try to release a new alpha every few weeks until we have the alpha-# issues converging towards 0. When we actually get to beta/rc releases then we can cut actual releases. Now about my allocation of issues, its not gospel! If you disagree with any of my assigning of fix versions then just fix it yourself (the version, or better yet the bug). At the time of this writing I have the 1.1-alpha-1 release down to a modest 8 issues with a few of those questionable and/or waiting for a bit of feedback. I have yet to go through the 200 or so unfiled issues though so that might go up a bit, I'll do that now. thoughts? jesse On 3/7/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: We don't need it the migration tool now. We'll can see to it when we'll release a first beta on rc. Emmanuel Brett Porter a écrit : On 07/03/2007, at 9:52 AM, Jesse McConnell wrote: Ok, well the little poll thread I made seemed to be strongly in favor of getting things pulled together to start getting alpha releases out of continuum. So with that in mind here is a list of a few things that we need to get in order for an alpha release that I shamelessly started base on bretts comments - properly mark up the model as it was for 1.0.3 release - add methods to continuum-data-management to utilise that and then make any necessary transformations (c-d-m will do the basic 1-to-1 conversions) - probably write a little CLI to fire it off. - vet jira for a 1.1 alpha 1 release version and maybe schedule out a couple of alpha-# releases. I think I'll start in on the data management bit now since that seems like the biggest hurdle. I am not convinced we really need to worry about a continuum 1.0.3 - continuum 1.1 migration ability...its not a difficult thing to get projects loaded back up into continuum...but
Re: Moving toward 2.0.6
On 3/12/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 11 Mar 07, at 9:48 PM 11 Mar 07, Jerome Lacoste wrote: [...] Some days ago we talked about trying to not expose the internal maven plexus-utils to the projects it builds. I have done work on trunk and am working with Torsten to finish the minijar plugin to hide internal dependencies. I see that 2.0.6 will have plexus-utils 1.4 ( http://jira.codehaus.org/browse/MNG-2828) but will the root issue be also fixed in 2.0.6 ? It's actually 1.4.1, but it's really the surefire plugin which is going to cause grief. Do you mean that hiding the dependencies will break the surefire plugin ? I have several plugins that would benefit from using the latest plexus-utils and if I got it right, they won't be able to do it until this is fixed. J
Re: Moving toward 2.0.6
On 12 Mar 07, at 12:22 AM 12 Mar 07, Jerome Lacoste wrote: On 3/12/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 11 Mar 07, at 9:48 PM 11 Mar 07, Jerome Lacoste wrote: [...] Some days ago we talked about trying to not expose the internal maven plexus-utils to the projects it builds. I have done work on trunk and am working with Torsten to finish the minijar plugin to hide internal dependencies. I see that 2.0.6 will have plexus-utils 1.4 ( http://jira.codehaus.org/browse/MNG-2828) but will the root issue be also fixed in 2.0.6 ? It's actually 1.4.1, but it's really the surefire plugin which is going to cause grief. Do you mean that hiding the dependencies will break the surefire plugin ? No, hiding the dependencies means that usage of p-u would be scrambled inside the Maven core, and plugins would be free to load whatever version of p-u they wanted to. Jason. I have several plugins that would benefit from using the latest plexus-utils and if I got it right, they won't be able to do it until this is fixed. J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archiva Database future.
Joakim Erdfelt wrote: Databases in Archiva. I need *desperately* to create a proper database for Archiva. Relying on the Lucene database for all things in Archiva is not cutting it. But I'm waffling on the database O/RM technology to use. Here some Archiva requirements for the O/RM db technology. 1) Need to be able to handle objects managed outside of Archiva. Why? It is very important to me to separate the internal API/model from the external API and model. They will be very similar in the beginning but will after a few releases start to differ and is necessary to stay backward compatible with old clients. We're already seeing this happening in Continuum 1.1 and is a natural way of developing code. There was once upon the time code in Modello to facilitate migrating objects from version to version when we tried to make Maven 2 read Maven 1 POMs (remember those days Jason?), which is why there are version fields on all attributes of a Modello model. I'm sure the same tricks can be used to make some xslt-like mapping structure in Modello to generate tools to copy data from internal to external objects. 2) Need to be able to work with objects managed by Archiva. 3) Needs to work with objects in without enhancements by O/RM. 4) Needs to support a wide variety of JDBC datasources. 5) Needs to be ASL license compatible. 6) Needs to be Open Source. 7) Need ability to upgrade schema of previously installed Archiva. 8) Needs to be quick. 9) Need to be active and support project. 10) Need to support arbitrary lookups across DB tables for reporting reasons. So, when I looked at the technologies out there, this is what I see. JPOX: Violates #3, #7, #8, #10. Hibernate: Violates #3, #5, #7, #10 OJB: Violates #3, #7 OpenJPA: Violates #3, #7, #10 iBatis: -- The problem I have with most of the O/RM technologies are around #3. The long term plans of Archiva are to create supporting technologies around the XML-RPC interface to the data that Archiva is tracking. Having enhanced objects would cause the clients to Archiva to also have these enhanced classes as well as the O/RM supporting jars. An unacceptable situation. Another big concern is #7 or how to upgrade the database schema between archiva releases. Most of the O/RM technologies above do not make it clear how they do that. So I dinged them. iBatis on the other hand makes it extremely clear. It doesn't manage the Table creation. The developer does it. The last concern is #10, or how well the O/RM technology can deal with arbitrary and dynamic lookups into the tables without working with the objects. Such as the needs of a reporting system. I would like to hook up the database tables to the various reporting libraries and presentation widgets without having to worry about those queries being invalidated by changes made to the schema by the O/RM technology. One Note, all of the reporting usage patterns against the database that I see are read-only in nature. The process I am proposing is to use modello and ibatis. * Create our archiva-model using modello. * Generate java files for model definition. * Generate Create Table sqlMap.xml files. - One for each database type (hsqldb, derby, mysql, oracle, etc...) - Only for version 1.0.0 in modello model. * Generate Update Table sqlMap.xml files. - One for each database type (hsqldb, derby, mysql, oracle, etc...) - For each versions above 1.0.0 in modello model. * Generate CRUD sqlMap.xml files. - One for each database type (hsqldb, derby, mysql, oracle, etc...) - One for each object in modello model. * Generate java source for table version. (to aide in upgrade logic) * Generate java source for ibatis DAO layer. - One for each object in modello model. * Generate java source for sqlmap table create / update usage. I am going to be working towards this starting monday. Unless anyone has some suggestions or criticism on this approach. I would love it if you could summarize your findings on the wiki, including the information you have here so it's possible to see where which technology fails in terms of your requirement list. -- Trygve
Re: Preparing for continuum-1.1-alpha-1
Jesse McConnell wrote: I have gone through jira issues there were assigned to 1.1 and spread things out a bit. here is my criteria I used in separating out the issues: 1.1-alpha-1 - issues that need to be addressed asap before we pull any kinda alpha 1.1-alpha-2 - higher importance issues and ones generally related to xml-rpc 1.1-alpha-# - issues that probably ought to be resolved in the alpha releases Future - stuff that probably ain't going to get done any day soon the idea being that we can make new sequential release issues off of the 1.1-alpha-# release tag until we are done with alpha releases. I think once 1.1-alpha-1 is released then we can go through 1.1-alpha-2 and decide what should be done, make a new release called 1.1-alpha-3 and bulk move issues that aren't going to be addressed then (like maybe all the xml-rpc issues) I think we shouldn't worry about making these actually releases cut with the maven-release-plugin. I say we just make a build and get it available for download. Also tag the continuum trunk accordingly. Then we ought to try to release a new alpha every few weeks until we have the alpha-# issues converging towards 0. Why not? Using the Maven plugin is generally easier than doing it by hand. Only issue that comes to mind are snapshots dependencies. When we actually get to beta/rc releases then we can cut actual releases. Now about my allocation of issues, its not gospel! If you disagree with any of my assigning of fix versions then just fix it yourself (the version, or better yet the bug). At the time of this writing I have the 1.1-alpha-1 release down to a modest 8 issues with a few of those questionable and/or waiting for a bit of feedback. I have yet to go through the 200 or so unfiled issues though so that might go up a bit, I'll do that now. Seems like a good pick, but I have a couple of comments: CONTINUUM-253: why? can't it be done after the release? CONTINUUM-827: sounds to me like this is something that can take a while, is it worth waiting for? Remember that the target for the next alpha should be within a month. What is the time estimate on completing all of the issues? -- Trygve
Re: Preparing for continuum-1.1-alpha-1
Jesse McConnell wrote: sounds good to me, imo either trunc it or maybe switch the model over to a clob for that in the db... I tried to make it a CLOB once but couldn't get it to work because of some JPOX issues IIRC so for alpha-1 just chop the exception and/or write it to a separate file and put the ideal solution into a later alpha. Keep moving! -- Trygve jesse On 3/9/07, Stephane Nicoll [EMAIL PROTECTED] wrote: On 3/9/07, Jesse McConnell [EMAIL PROTECTED] wrote: I have gone through jira issues there were assigned to 1.1 and spread things out a bit. here is my criteria I used in separating out the issues: 1.1-alpha-1 - issues that need to be addressed asap before we pull any kinda alpha Not because I opened this but I think CONTINUUM-1194 should be fixed. I'll try to provide a patch this sunday for this. As a summary, if an error occurs and the stacktrace is higher than 8000 chars: * The build is stuck in Build In Progress * No notification is triggered (an error has occured?!) Thanks, Stéphane 1.1-alpha-2 - higher importance issues and ones generally related to xml-rpc 1.1-alpha-# - issues that probably ought to be resolved in the alpha releases Future - stuff that probably ain't going to get done any day soon the idea being that we can make new sequential release issues off of the 1.1-alpha-# release tag until we are done with alpha releases. I think once 1.1-alpha-1 is released then we can go through 1.1-alpha-2 and decide what should be done, make a new release called 1.1-alpha-3 and bulk move issues that aren't going to be addressed then (like maybe all the xml-rpc issues) I think we shouldn't worry about making these actually releases cut with the maven-release-plugin. I say we just make a build and get it available for download. Also tag the continuum trunk accordingly. Then we ought to try to release a new alpha every few weeks until we have the alpha-# issues converging towards 0. When we actually get to beta/rc releases then we can cut actual releases. Now about my allocation of issues, its not gospel! If you disagree with any of my assigning of fix versions then just fix it yourself (the version, or better yet the bug). At the time of this writing I have the 1.1-alpha-1 release down to a modest 8 issues with a few of those questionable and/or waiting for a bit of feedback. I have yet to go through the 200 or so unfiled issues though so that might go up a bit, I'll do that now. thoughts? jesse On 3/7/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: We don't need it the migration tool now. We'll can see to it when we'll release a first beta on rc. Emmanuel Brett Porter a écrit : On 07/03/2007, at 9:52 AM, Jesse McConnell wrote: Ok, well the little poll thread I made seemed to be strongly in favor of getting things pulled together to start getting alpha releases out of continuum. So with that in mind here is a list of a few things that we need to get in order for an alpha release that I shamelessly started base on bretts comments - properly mark up the model as it was for 1.0.3 release - add methods to continuum-data-management to utilise that and then make any necessary transformations (c-d-m will do the basic 1-to-1 conversions) - probably write a little CLI to fire it off. - vet jira for a 1.1 alpha 1 release version and maybe schedule out a couple of alpha-# releases. I think I'll start in on the data management bit now since that seems like the biggest hurdle. I am not convinced we really need to worry about a continuum 1.0.3 - continuum 1.1 migration ability...its not a difficult thing to get projects loaded back up into continuum...but we'll see I guess. It is a pain, but having said that we could potentially add it in a later milestone. I wouldn't want a final version without it. anyone have anything to add? jesse --jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Does this feature already exist?
It is indeed similar but Erik's thing will build it against *all* compatible versions, where compatible means within major upgrades (a x.y.z pattern is assumed). -- Trygve Jesse McConnell wrote: erik I saw this issue and thought of you :) http://jira.codehaus.org/browse/CONTINUUM-45 jesse On 3/8/07, Erik Drolshammer [EMAIL PROTECTED] wrote: Brett Porter wrote: On 08/03/2007, at 11:47 AM, Erik Drolshammer wrote: Did this make it clearer? yes Has Continuum 1.1 anything that resembles this? no Puuh. I was a bit scared now. Kind of. this would certainly facilitate it though. cool! I hope so. :) -- Regards Erik
Re: Moving toward 2.0.6
I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let it still use 1.1. All previous releases (except for beta releases) use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more than just surefire. Jason van Zyl wrote: On 12 Mar 07, at 12:22 AM 12 Mar 07, Jerome Lacoste wrote: On 3/12/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 11 Mar 07, at 9:48 PM 11 Mar 07, Jerome Lacoste wrote: [...] Some days ago we talked about trying to not expose the internal maven plexus-utils to the projects it builds. I have done work on trunk and am working with Torsten to finish the minijar plugin to hide internal dependencies. I see that 2.0.6 will have plexus-utils 1.4 ( http://jira.codehaus.org/browse/MNG-2828) but will the root issue be also fixed in 2.0.6 ? It's actually 1.4.1, but it's really the surefire plugin which is going to cause grief. Do you mean that hiding the dependencies will break the surefire plugin ? No, hiding the dependencies means that usage of p-u would be scrambled inside the Maven core, and plugins would be free to load whatever version of p-u they wanted to. Jason. I have several plugins that would benefit from using the latest plexus-utils and if I got it right, they won't be able to do it until this is fixed. J - 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: [Archetypes] plugin proposition
My current task is now to document what i have done so far. Answers and questions inlined. Raphaël 2007/3/12, Brett Porter [EMAIL PROTECTED]: My basic feedback would be similar to Jason's. Key requirements: - backwards compatibility with existing archetypes is a definite requirement Is backward compatibility for archetype only the recognition of the old descriptor and pathes resolution ? The selection step of the proposition can not enforce compatibility as it is based on repository-metadata (like maven-plugins). - existing goal names need to continue to work, even if they are deprecated I have some trouble with this as: old goals are: create and create-from-project and the new mapping proposed is generate instead of create and create instead of create-from-project. I would also note that in the jira the components are : creator for create-from-project and generator for create. - if it's being designed from the ground up, it should have new standards of testing and documentation I must admit not understaning well what has to be done here. My main query is whether this needed a rewrite or whether it could be done as incremental advancements on the current code base? It's obviously a lot easier to consume that way as long as someone is committed to reviewing and applying patches in short order. I would say that i can't see a path of patches. Please read the proposition code to be sure. Some more questions: On 08/03/2007, at 10:54 AM, Raphaël Piéroni wrote: - package mojo: to jar the created archetype How is this different to a normal JAR that it needs it's own packaging? Isn't it just additional resources in the lifecycle? What i see here is just a jar around the created archetype's directory. I would also create a new packaging to provide the following functionnalities: - At install and deployment phases, an archetype needs the repository metadata to be updated (the same way as maven-plugin) - sample properties mojo: to provide a sample configuration file for an archetype (which could be filled and used in batch mode) What are the current needs of a configuration file? I figured that even with the one we currently had, most of that could have been autodiscovered from the archetype resources. What i see here is a mojo which write a sample property file to be used in the generation of the project. That sample file would contains the archetype definition, and the values of the required properties of the archetype. with those properties valuated using the archetype's default values. The properties without a default values will only be set to empty (or to please_configure_this_property) - descriptor with attributes: refactor the current archetype descriptor to use attributes instead of xml elements Less is more :) By current i mean the current in the proposition. I don't understand the subtlety of less is more. - generate multi project: to generate a project and its internal modules from one archetype. Cool. I assume you are retaining the functionality I added where you can incrementally add to a multiproject as well? The main problem here is an archetype of a multiproject. like the ear (ejb) archetype. And also to create suche an archetype from an existing project. The current proposition can generate a project in partial mode, and also generate a subproject in an existing project (and insert a parent element in the generated pom - and a module in the parent project). - CRUD group mojo: mojos to change the archetype groups defined in the ~/.m2/archetypes.xml Don't really understand this, nor what archetypes.xml is for. Archetype.xml is a file which holds the list of archetype groups (just like the pluginGroups in tsettings.xml) That mojo will only be used to change the xml file. this mojo is only for convenience and will not be really important. - Documentation: Document the workfow of user interaction, explain the internal plexus components +1 :) It is what i'm doning for now. i will sent a link to the generated html file as soon as i have completed it (at least wednesday and at most in 2 weeks) - integration tests and sibling: handle directories other than src/ main, src/test, src/site. a first case would be integration tests +1 :) - pom.xml sibling: handle templates in the main directory. some use case would be readme files - translator: create a tool to translate current archetypes into this new way Wouldn't worry too much about this as loong as it remains backwards compatible. It should be very straight forward to do by hand if the implementation is simple enough to do it from scratch. The translator will provide the may to enhance the metadata for the selection. - archetype group metadata: create a new group metadata for archetypes (same way as plugins metadata) therefore we could have a archetype packaging. +1 - velocity tools in templates: provide the official velocity tools to be used by
Re: [Archetypes] plugin proposition
Oups, I forgotten to say that archetypes is the first foot a developper starts for using maven. This is why i'm concerned about archetypes. I also see archetypes a examples of using maven (for example the axistools) Raphaël 2007/3/12, Raphaël Piéroni [EMAIL PROTECTED]: My current task is now to document what i have done so far. Answers and questions inlined. Raphaël 2007/3/12, Brett Porter [EMAIL PROTECTED] : My basic feedback would be similar to Jason's. Key requirements: - backwards compatibility with existing archetypes is a definite requirement Is backward compatibility for archetype only the recognition of the old descriptor and pathes resolution ? The selection step of the proposition can not enforce compatibility as it is based on repository-metadata (like maven-plugins). - existing goal names need to continue to work, even if they are deprecated I have some trouble with this as: old goals are: create and create-from-project and the new mapping proposed is generate instead of create and create instead of create-from-project. I would also note that in the jira the components are : creator for create-from-project and generator for create. - if it's being designed from the ground up, it should have new standards of testing and documentation I must admit not understaning well what has to be done here. My main query is whether this needed a rewrite or whether it could be done as incremental advancements on the current code base? It's obviously a lot easier to consume that way as long as someone is committed to reviewing and applying patches in short order. I would say that i can't see a path of patches. Please read the proposition code to be sure. Some more questions: On 08/03/2007, at 10:54 AM, Raphaël Piéroni wrote: - package mojo: to jar the created archetype How is this different to a normal JAR that it needs it's own packaging? Isn't it just additional resources in the lifecycle? What i see here is just a jar around the created archetype's directory. I would also create a new packaging to provide the following functionnalities: - At install and deployment phases, an archetype needs the repository metadata to be updated (the same way as maven-plugin) - sample properties mojo: to provide a sample configuration file for an archetype (which could be filled and used in batch mode) What are the current needs of a configuration file? I figured that even with the one we currently had, most of that could have been autodiscovered from the archetype resources. What i see here is a mojo which write a sample property file to be used in the generation of the project. That sample file would contains the archetype definition, and the values of the required properties of the archetype. with those properties valuated using the archetype's default values. The properties without a default values will only be set to empty (or to please_configure_this_property) - descriptor with attributes: refactor the current archetype descriptor to use attributes instead of xml elements Less is more :) By current i mean the current in the proposition. I don't understand the subtlety of less is more. - generate multi project: to generate a project and its internal modules from one archetype. Cool. I assume you are retaining the functionality I added where you can incrementally add to a multiproject as well? The main problem here is an archetype of a multiproject. like the ear (ejb) archetype. And also to create suche an archetype from an existing project. The current proposition can generate a project in partial mode, and also generate a subproject in an existing project (and insert a parent element in the generated pom - and a module in the parent project). - CRUD group mojo: mojos to change the archetype groups defined in the ~/.m2/archetypes.xml Don't really understand this, nor what archetypes.xml is for. Archetype.xml is a file which holds the list of archetype groups (just like the pluginGroups in tsettings.xml ) That mojo will only be used to change the xml file. this mojo is only for convenience and will not be really important. - Documentation: Document the workfow of user interaction, explain the internal plexus components +1 :) It is what i'm doning for now. i will sent a link to the generated html file as soon as i have completed it (at least wednesday and at most in 2 weeks) - integration tests and sibling: handle directories other than src/ main, src/test, src/site. a first case would be integration tests +1 :) - pom.xml sibling: handle templates in the main directory. some use case would be readme files - translator: create a tool to translate current archetypes into this new way Wouldn't worry too much about this as loong as it remains backwards compatible. It should be very straight forward to do by hand if the implementation is simple enough to do it from scratch. The translator will provide
Re: Trouble w/ the Plexus app and on Tomcat r516446
There is a mismatch of plexus component api and container-default by the looks of things, unless there is some code in archiva that uses the removed getComponentKey() method. Andy On 11 Mar 2007, at 20:04, Wendy Smoak wrote: On 3/11/07, Brett Porter [EMAIL PROTECTED] wrote: This occurs when you use an older database that was on jpox 1.1.4, and run it under the new stuff, unfortunately. You probably need to start over with your users database. Thanks. That fixed it for Tomcat (once I figured out where the databases were hiding-- I had set derby.system.home to keep them out of $TOMCAT_HOME/bin.) The Plexus runtime still won't work though: The error with Plexus is jvm 1| WrapperSimpleApp: Encountered an error running main: java.lang.NoSuch MethodError: org.codehaus.plexus.component.repository.ComponentDescriptor.getCom ponentKey()Ljava/lang/String; jvm 1| java.lang.NoSuchMethodError: org.codehaus.plexus.component.repository .ComponentDescriptor.getComponentKey()Ljava/lang/String; Does that look familiar to anyone? -- Wendy
Re: Trouble w/ the Plexus app and on Tomcat r516446
The runtime works fine there. Check your core directory. Do you have plexus-component-api-1.0-alpha-18.jar, plexus-container-default-1.0-alpha-18.jar and plexus-appserver-host-2.0-alpha-8-SNAPSHOT.jar ? Emmanuel Brett Porter a écrit : Emmanuel last changed the container - anything to do with that? On 11/03/2007, at 1:04 PM, Wendy Smoak wrote: On 3/11/07, Brett Porter [EMAIL PROTECTED] wrote: This occurs when you use an older database that was on jpox 1.1.4, and run it under the new stuff, unfortunately. You probably need to start over with your users database. Thanks. That fixed it for Tomcat (once I figured out where the databases were hiding-- I had set derby.system.home to keep them out of $TOMCAT_HOME/bin.) The Plexus runtime still won't work though: The error with Plexus is jvm 1| WrapperSimpleApp: Encountered an error running main: java.lang.NoSuch MethodError: org.codehaus.plexus.component.repository.ComponentDescriptor.getCom ponentKey()Ljava/lang/String; jvm 1| java.lang.NoSuchMethodError: org.codehaus.plexus.component.repository .ComponentDescriptor.getComponentKey()Ljava/lang/String; Does that look familiar to anyone? --Wendy
Re: Moving toward 2.0.6
On 3/12/07, Kenney Westerhof [EMAIL PROTECTED] wrote: I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let it still use 1.1. All previous releases (except for beta releases) use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more than just surefire. I agree. But even hiding 1.1 will probably affect some plugins that used to refer to a higher version of p-u without knowing it wasn't really in use. It's a smaller problem. I am curious as to see how many plugins will be affected. J
release:perform and classifier breakage
Hi all,
I am trying to do a release:perform on a project that creates a jar with a
classifier.
For some reason, as part of release:perform, install:install is called,
and when install:install is called _without_ being part of the build
lifecycle, it fails with the error below.
I tried configuring the install plugin to have a classifier, but to no avail.
I also tried setting the finalName to the name+version+classifier, but
also to no avail:
finalName${artifactId}-${version}-${os-platform}-${os-arch}/finalName
Has anyone seen release:perform work with a classifier present?
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] Building jar:
/udd001/app/alchemy/development/native-new/trunk/target/checkout/alchemy-cdo/target/alchemy-cdo-4.0.6-sources.jar
[INFO] [install:install]
[INFO] No primary artifact to install, installing attached artifacts
instead.
[INFO] Installing
/udd001/app/alchemy/development/native-new/trunk/target/checkout/alchemy-cdo/target/alchemy-cdo-4.0.6-linux-Linux
amd64.jar to
/udd001/app/alchemy/.m2/repository/alchemy/alchemy-cdo/4.0.6/alchemy-cdo-4.0.6-linux-Linux
amd64.jar
[INFO] Installing
/udd001/app/alchemy/development/native-new/trunk/target/checkout/alchemy-cdo/target/alchemy-cdo-4.0.6-sources.jar
to
/udd001/app/alchemy/.m2/repository/alchemy/alchemy-cdo/4.0.6/alchemy-cdo-4.0.6-sources.jar
[INFO] [deploy:deploy]
altDeploymentRepository = null
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error deploying artifact:
/udd001/app/alchemy/development/native-new/trunk/target/checkout/alchemy-cdo/target/classes
(Is a directory)
Regards,
Graham
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceManager issues in reporting plugins...
Quick updates: 1) It's definitely the classloader. If a set the contextClassLoader to the classloader of the plugin, the RM works fine. That seems like less of a hack so I'll go with that. 2) I THINK this is the cause of MCHECKSTYLE-65. I'll try the classloader thing there too. Dan On Monday 12 March 2007 10:57, Daniel Kulp wrote: Jason, Back in December, you changed a bunch of plugins (PMD and Checkstyle are definitely two of them) to use the ResourceManager instead of the custom Locator code they had. That seems to work fine when the plugins are part of the actual build build, but not during a reporting run.If there are config files that are part of a dependency jar (obviously configured in pluginManagement section due to reporting section not having dependencies), during a regular build, the call to rm.getResourceAsFile() passing a classpath relative string works perfectly. However, during a mvn site run, that ends up throwing an exception as the resource cannot be found.For PMD, I explicitly catch the exception and then call this.getClass().getClassLoader().getResource() which DOES work. Thus, I know the plugin itself is picking up the dependencies correctly. It's just the ResourceManager that is not configured completely correctly. Any ideas? Is the thread contextClassloader not being set properly during reporting? -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble w/ the Plexus app and on Tomcat r516446
I don't know how you can get alpha-19-SNAPSHOT, but I added plexus-component-api in archiva-plexus-runtime so it should be ok now. Emmanuel Wendy Smoak a écrit : On 3/12/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: The runtime works fine there. Check your core directory. Do you have plexus-component-api-1.0-alpha-18.jar, plexus-container-default-1.0-alpha-18.jar and plexus-appserver-host-2.0-alpha-8-SNAPSHOT.jar ? I have: [EMAIL PROTECTED] /cygdrive/c/java/archiva-r516446/core $ ls plexus* plexus-appserver-host-2.0-alpha-8-SNAPSHOT.jar plexus-naming-1.0-alpha-3.jar plexus-component-api-1.0-alpha-19-SNAPSHOT.jar plexus-utils-1.4.jar plexus-container-default-1.0-alpha-18.jar I have a different component-api jar than you listed-- 1.0-alpha-19-SNAPSHOT vs your 1.0-alpha-18. And as I have different version numbers on component-api and container-default, it sounds like the mismatch Andy mentions.
ResourceManager issues in reporting plugins...
Jason, Back in December, you changed a bunch of plugins (PMD and Checkstyle are definitely two of them) to use the ResourceManager instead of the custom Locator code they had. That seems to work fine when the plugins are part of the actual build build, but not during a reporting run.If there are config files that are part of a dependency jar (obviously configured in pluginManagement section due to reporting section not having dependencies), during a regular build, the call to rm.getResourceAsFile() passing a classpath relative string works perfectly. However, during a mvn site run, that ends up throwing an exception as the resource cannot be found.For PMD, I explicitly catch the exception and then call this.getClass().getClassLoader().getResource() which DOES work. Thus, I know the plugin itself is picking up the dependencies correctly. It's just the ResourceManager that is not configured completely correctly. Any ideas? Is the thread contextClassloader not being set properly during reporting? -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release:perform and classifier breakage
On Mon, March 12, 2007 4:34 pm, Graham Leggett wrote:
Has anyone seen release:perform work with a classifier present?
I have managed to narrow this down to the deploy plugin. It seems the
deploy plugin cannot deploy a jar with a classifier. The stacktrace is
below.
[INFO] [jar:jar]
[INFO] Building jar:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/alchemy-cdo-4.0.6-SNAPSHOT-macosx-ppc.jar
[INFO] [build-helper:attach-artifact {execution: attach-artifacts}]
[INFO] [install:install]
[INFO] No primary artifact to install, installing attached artifacts instead.
[INFO] Installing
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/alchemy-cdo-4.0.6-SNAPSHOT-macosx-ppc.jar
to
/Users/minfrin/.m2/repository/alchemy/alchemy-cdo/4.0.6-SNAPSHOT/alchemy-cdo-4.0.6-SNAPSHOT-macosx-ppc.jar
[INFO] Installing
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/alchemy-cdo-4.0.6-SNAPSHOT-macosx-ppc.jar
to
/Users/minfrin/.m2/repository/alchemy/alchemy-cdo/4.0.6-SNAPSHOT/alchemy-cdo-4.0.6-SNAPSHOT-macosx-ppc.jar
[INFO] [deploy:deploy]
altDeploymentRepository = null
[INFO] Retrieving previous build number from alchemy.scmb.co.za
WAGON_VERSION: 1.0-beta-2
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error deploying artifact:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/classes
(No such file or directory)
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
artifact:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/classes
(No such file or directory)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying
artifact:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/classes
(No such file or directory)
at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:174)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
... 16 more
Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
Error deploying artifact:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/classes
(No such file or directory)
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:95)
at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:162)
... 18 more
Caused by: java.io.FileNotFoundException:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/classes
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820)
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:74)
... 19 more
Regards,
Graham
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Re: Trouble w/ the Plexus app and on Tomcat r516446
On 3/12/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: The runtime works fine there. Check your core directory. Do you have plexus-component-api-1.0-alpha-18.jar, plexus-container-default-1.0-alpha-18.jar and plexus-appserver-host-2.0-alpha-8-SNAPSHOT.jar ? I have: [EMAIL PROTECTED] /cygdrive/c/java/archiva-r516446/core $ ls plexus* plexus-appserver-host-2.0-alpha-8-SNAPSHOT.jar plexus-naming-1.0-alpha-3.jar plexus-component-api-1.0-alpha-19-SNAPSHOT.jar plexus-utils-1.4.jar plexus-container-default-1.0-alpha-18.jar I have a different component-api jar than you listed-- 1.0-alpha-19-SNAPSHOT vs your 1.0-alpha-18. And as I have different version numbers on component-api and container-default, it sounds like the mismatch Andy mentions. -- Wendy
Re: svn commit: r516945 - in /maven/site/trunk/src/site/apt: download.apt download.apt.template insert-project-version.sh
On 3/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Sun Mar 11 09:27:08 2007
New Revision: 516945
URL: http://svn.apache.org/viewvc?view=revrev=516945
Log:
o little script to swap in the versions, until the site plugin can do it, this
will do. i'm tired of changing N documents each release so
i'll update this script and it can be the basis for the configuration of a
new option in site plugin.
Some combination of this commit and r516959 have effectively broken
mvn site. The ${project.version} expressions are in download.apt,
not just in the template.
The download page now has links like:
http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-$%7Bproject.version
I thought the idea was to use the script and template to generate
download.apt, and then check in the changes, but that's not what
happened here.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving toward 2.0.6
Yes, I can add the override model option in; I'm fairly busy presently, but I can hopefully have something out in the next day or two. Patrick On 3/12/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 11 Mar 07, at 4:02 PM 11 Mar 07, Ralph Goers wrote: Jason, Well, I view the behavior of the patch as being correct, but since the override flag has been removed from the pom it breaks backward compatibility with previous 2.0 verisons - which is why I added the flag in the first place. However, if anyone complains about this it should be pointed out that the prior behavior was very unpredictable. I think as we discussed it should have the current behavior, even if it is highly erratic, and have it be consciously turned on. Who knows who is relying on the quirks. Patrick, can we put the option in the model to turn this features on please? Jason. Ralph Jason van Zyl wrote: Hi, I've got three issues left to close out for 2.0.6 and two of them I will finish tomorrow and the snapshot weirdness I will fix wed/ thurs. But if anyone wants to try what's there so far it's here: http://idisk.maven.org/jvanzyl/Public/maven/ I imagine the MNG-1577 might spark some discussion and require changes but I'm shooting for a vote this wed/thurs as soon as I resolve the snapshot issues. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving toward 2.0.6
On 12 Mar 07, at 2:23 AM 12 Mar 07, Kenney Westerhof wrote: I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let it still use 1.1. All previous releases (except for beta releases) use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more than just surefire. I certainly do the hiding, it's not that big of a deal. I think rolling back now would break other things and we should be free to use internally what we need and not have that affect its use elsewhere. Jason. Jason van Zyl wrote: On 12 Mar 07, at 12:22 AM 12 Mar 07, Jerome Lacoste wrote: On 3/12/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 11 Mar 07, at 9:48 PM 11 Mar 07, Jerome Lacoste wrote: [...] Some days ago we talked about trying to not expose the internal maven plexus-utils to the projects it builds. I have done work on trunk and am working with Torsten to finish the minijar plugin to hide internal dependencies. I see that 2.0.6 will have plexus-utils 1.4 ( http://jira.codehaus.org/browse/MNG-2828) but will the root issue be also fixed in 2.0.6 ? It's actually 1.4.1, but it's really the surefire plugin which is going to cause grief. Do you mean that hiding the dependencies will break the surefire plugin ? No, hiding the dependencies means that usage of p-u would be scrambled inside the Maven core, and plugins would be free to load whatever version of p-u they wanted to. Jason. I have several plugins that would benefit from using the latest plexus-utils and if I got it right, they won't be able to do it until this is fixed. J - 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: Moving toward 2.0.6
On 12 Mar 07, at 6:15 AM 12 Mar 07, Jerome Lacoste wrote: On 3/12/07, Kenney Westerhof [EMAIL PROTECTED] wrote: I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let it still use 1.1. All previous releases (except for beta releases) use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more than just surefire. I agree. But even hiding 1.1 will probably affect some plugins that used to refer to a higher version of p-u without knowing it wasn't really in use. No it shouldn't affect them at all. Plugins can specify the exact version they needed. The version used in the core will be invisible. Jason. It's a smaller problem. I am curious as to see how many plugins will be affected. J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceManager issues in reporting plugins...
I stumbled upon this issue over the weekend. If you are using the trunk version from svn of the Checkstyle plugin, you cannot build the site for any of our own plugins. I managed to work around it by explicitly specifying maven-checkstyle-plugin version 2.1 temporarily in the pom. I got the same message as in MCHECKSTYLE-65. Daniel Kulp wrote: Jason, Back in December, you changed a bunch of plugins (PMD and Checkstyle are definitely two of them) to use the ResourceManager instead of the custom Locator code they had. That seems to work fine when the plugins are part of the actual build build, but not during a reporting run.If there are config files that are part of a dependency jar (obviously configured in pluginManagement section due to reporting section not having dependencies), during a regular build, the call to rm.getResourceAsFile() passing a classpath relative string works perfectly. However, during a mvn site run, that ends up throwing an exception as the resource cannot be found.For PMD, I explicitly catch the exception and then call this.getClass().getClassLoader().getResource() which DOES work. Thus, I know the plugin itself is picking up the dependencies correctly. It's just the ResourceManager that is not configured completely correctly. Any ideas? Is the thread contextClassloader not being set properly during reporting? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JXR 1.1
Arnaud HERITIER wrote: On 3/5/07, Brett Porter [EMAIL PROTECTED] wrote: On 04/03/2007, at 4:05 PM, Dennis Lundberg wrote: I found a couple of other bugs while testing, that I also fixed. I feel pretty much done now. Snapshots have been deployed so that'll give it some testing. cool, thanks for this! How about moving the plugin into the same source tree and releasing a unified version, as we are doing with all the others like surefire? Sure that can be done. That'd be a unified version of 2.1 I guess, since that is the largest version of the two (jxr is at 1.1- SNAPSHOT and jxr-plugin is at 2.1-SNAPSHOT). Yeah - though it raises the question of what to do with the maven1 plugin. We could pull that in too, build it with the maven-one- plugin, and give it a version of 2.1 as well, using group ID to differentiate. Not sure how Arnaud and Lukas feel about that? If we can build the JXR plugin for maven 1 with maven 2, let's go for it ;-) We'll just deprecate our code and we'll update our plugins list descriptor to bundle it in the next release. It's not in our interest to duplicate a plugin. We have enough work with all the others. Arnaud I'll try to see if I can get this to work, starting with a temporary copy of the Maven 1 plugin. If I get that working, I'll get back and we can discuss how to best do the subversion migration and plugin-bundling in Maven 1. snip/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceManager issues in reporting plugins...
Dennis, On Monday 12 March 2007 12:04, Dennis Lundberg wrote: I stumbled upon this issue over the weekend. If you are using the trunk version from svn of the Checkstyle plugin, you cannot build the site for any of our own plugins. I managed to work around it by explicitly specifying maven-checkstyle-plugin version 2.1 temporarily in the pom. I got the same message as in MCHECKSTYLE-65. I deployed a new snapshot about an hour ago that I fixes this problem. (it was breaking the builds of some projects like Apache Yoko which use snapshots) I moved the setting of the contextClassLoader to before resolving the locations of the various files. That seems to fix the issue most of the time. I'm having some issues with the suppression files, but I hope to have that fixed in the next 1/2 hour or so. Dan Daniel Kulp wrote: Jason, Back in December, you changed a bunch of plugins (PMD and Checkstyle are definitely two of them) to use the ResourceManager instead of the custom Locator code they had. That seems to work fine when the plugins are part of the actual build build, but not during a reporting run.If there are config files that are part of a dependency jar (obviously configured in pluginManagement section due to reporting section not having dependencies), during a regular build, the call to rm.getResourceAsFile() passing a classpath relative string works perfectly. However, during a mvn site run, that ends up throwing an exception as the resource cannot be found.For PMD, I explicitly catch the exception and then call this.getClass().getClassLoader().getResource() which DOES work. Thus, I know the plugin itself is picking up the dependencies correctly. It's just the ResourceManager that is not configured completely correctly. Any ideas? Is the thread contextClassloader not being set properly during reporting? -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving toward 2.0.6
I think what he is saying is that plugins out there may declare a newer version of p-u (like mdep) that tested to work with that version ok (so we thought) because it was really using the mvn core version. If suddenly you allow plugins to use their own declared versions, they may suddenly not work. It's a risk, but I think it needs to be done. The only thing we can do is allow the use in the snapshot, and then test the plugins to see if they work or suddenly break and see if we can get fixes timed to release with 2.0.6. After all, the fix would be to just roll back the p-u version to whatever 2.0.5 enforced in the broken plugin's pom so it should be easy (especially if we go back to the release and make a patch release from the tag) --Brian -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, March 12, 2007 12:01 PM To: Maven Developers List Subject: Re: Moving toward 2.0.6 On 12 Mar 07, at 6:15 AM 12 Mar 07, Jerome Lacoste wrote: On 3/12/07, Kenney Westerhof [EMAIL PROTECTED] wrote: I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let it still use 1.1. All previous releases (except for beta releases) use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more than just surefire. I agree. But even hiding 1.1 will probably affect some plugins that used to refer to a higher version of p-u without knowing it wasn't really in use. No it shouldn't affect them at all. Plugins can specify the exact version they needed. The version used in the core will be invisible. Jason. It's a smaller problem. I am curious as to see how many plugins will be affected. J - 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]
PMD plugin remaining issues...
As you probably saw on the commit list, I did a bunch of commits for PMD over the weekend. At this point, there is only one remaining issue open for 2.2. (MPMD-41) To fix that completely, I need part of the objectweb m2 repository synced to central. (asm/**/*)I've included the current release notes below. The three remaining open issues are: [MPMD-22] - dependencies in reporting section. Will be fixed when MNG-2173 is fixed. Workaround does exist. [MPMD-39] - target jdk version from compiler. Probably best to delay till we have a shared context. Anything we do now would be a hack. [MPMD-17] - report summary at top of html. This is a minor improvement request. However, it would involve a complete re-write of how the html report is created. Thus, I'd like to push this off for now. Thus, once the repository is synced, I'd like to release this.It's been over 8 months since the last release so I'd like to get this out there. Are there any objections or concerns? Does everyone agree with not doing the above three for this release? Thanks! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog Release Notes - Maven 2.x Pmd Plugin - Version 2.2 ** Bug * [MPMD-30] - No way to PMD test the test sources in src/test/java * [MPMD-47] - pmd should support multiple source roots * [MPMD-50] - Reports are different depending on the order of files retrieved from the filesystem * [MPMD-51] - Sometimes PMD.xml doesn't contain the class name and this displays null in the verbose mode * [MPMD-52] - XRef lnks do not work with aggregated XRef ** Improvement * [MPMD-28] - Support for multi-projects poms * [MPMD-38] - Add Posibility to excludes files in Cpd * [MPMD-40] - deploy the pmd.xml with site:deploy * [MPMD-44] - Allow to specify the rulesets as described in the docs * [MPMD-46] - Add ability to choose priority for failure * [MPMD-53] - pmd mojos need a skip flag similar to surefire ** New Feature * [MPMD-43] - Add results output to pmd:check * [MPMD-49] - Add results output to cpd:check ** Task * [MPMD-41] - Upgrade to PMD 3.9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PMD plugin remaining issues...
+1. I've been running a snapshot rev from around sept, an official version would be handy. -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Monday, March 12, 2007 1:17 PM To: dev@maven.apache.org Subject: PMD plugin remaining issues... As you probably saw on the commit list, I did a bunch of commits for PMD over the weekend. At this point, there is only one remaining issue open for 2.2. (MPMD-41) To fix that completely, I need part of the objectweb m2 repository synced to central. (asm/**/*)I've included the current release notes below. The three remaining open issues are: [MPMD-22] - dependencies in reporting section. Will be fixed when MNG-2173 is fixed. Workaround does exist. [MPMD-39] - target jdk version from compiler. Probably best to delay till we have a shared context. Anything we do now would be a hack. [MPMD-17] - report summary at top of html. This is a minor improvement request. However, it would involve a complete re-write of how the html report is created. Thus, I'd like to push this off for now. Thus, once the repository is synced, I'd like to release this.It's been over 8 months since the last release so I'd like to get this out there. Are there any objections or concerns? Does everyone agree with not doing the above three for this release? Thanks! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog Release Notes - Maven 2.x Pmd Plugin - Version 2.2 ** Bug * [MPMD-30] - No way to PMD test the test sources in src/test/java * [MPMD-47] - pmd should support multiple source roots * [MPMD-50] - Reports are different depending on the order of files retrieved from the filesystem * [MPMD-51] - Sometimes PMD.xml doesn't contain the class name and this displays null in the verbose mode * [MPMD-52] - XRef lnks do not work with aggregated XRef ** Improvement * [MPMD-28] - Support for multi-projects poms * [MPMD-38] - Add Posibility to excludes files in Cpd * [MPMD-40] - deploy the pmd.xml with site:deploy * [MPMD-44] - Allow to specify the rulesets as described in the docs * [MPMD-46] - Add ability to choose priority for failure * [MPMD-53] - pmd mojos need a skip flag similar to surefire ** New Feature * [MPMD-43] - Add results output to pmd:check * [MPMD-49] - Add results output to cpd:check ** Task * [MPMD-41] - Upgrade to PMD 3.9 - 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: Moving toward 2.0.6
On 12 Mar 07, at 10:06 AM 12 Mar 07, Brian E. Fox wrote: I think what he is saying is that plugins out there may declare a newer version of p-u (like mdep) that tested to work with that version ok (so we thought) because it was really using the mvn core version. If suddenly you allow plugins to use their own declared versions, they may suddenly not work. I believe the only problem is with the command line utils. But you will find out in very short order if it doesn't work. And if you have tests then you're fine. It's a risk, but I think it needs to be done. The only thing we can do is allow the use in the snapshot, and then test the plugins to see if they work or suddenly break and see if we can get fixes timed to release with 2.0.6. After all, the fix would be to just roll back the p-u version to whatever 2.0.5 enforced in the broken plugin's pom so it should be easy (especially if we go back to the release and make a patch release from the tag) It's a move in the right direction of complete isolation. The next magic trick is creation an execution environment (i.e. a plexus container) containing the set of dependencies needed for a specific version of our plugin apis. So if you have 5 different plugins that have been bound to 5 different versions of the plugin api then they will all run in isolation and everything will be fine. This is how I see all plugins being created/executed in the 2.0.x context running perfectly fine in 2.1.x. So accommodating the any previous plugins along with improvements that we are going to make in 2.1.x. Jason. --Brian -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, March 12, 2007 12:01 PM To: Maven Developers List Subject: Re: Moving toward 2.0.6 On 12 Mar 07, at 6:15 AM 12 Mar 07, Jerome Lacoste wrote: On 3/12/07, Kenney Westerhof [EMAIL PROTECTED] wrote: I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let it still use 1.1. All previous releases (except for beta releases) use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more than just surefire. I agree. But even hiding 1.1 will probably affect some plugins that used to refer to a higher version of p-u without knowing it wasn't really in use. No it shouldn't affect them at all. Plugins can specify the exact version they needed. The version used in the core will be invisible. Jason. It's a smaller problem. I am curious as to see how many plugins will be affected. J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r517432 - in /maven/site/trunk/src/site/apt: download.apt download.apt.template insert-project-version.sh
should download.apt be removed from svn if it is generated?
On 12/03/2007, at 3:29 PM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Mon Mar 12 15:29:43 2007
New Revision: 517432
URL: http://svn.apache.org/viewvc?view=revrev=517432
Log:
o fix the generation script and encourage is spelt like that even
in Americanese.
Modified:
maven/site/trunk/src/site/apt/download.apt
maven/site/trunk/src/site/apt/download.apt.template
maven/site/trunk/src/site/apt/insert-project-version.sh
Modified: maven/site/trunk/src/site/apt/download.apt
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/
download.apt?view=diffrev=517432r1=517431r2=517432
==
--- maven/site/trunk/src/site/apt/download.apt (original)
+++ maven/site/trunk/src/site/apt/download.apt Mon Mar 12 15:29:43
2007
@@ -16,7 +16,7 @@
Maven 2.0.5 is distributed under the {{{http://maven.apache.org/
license.html} Apache License, version 2.0}}.
- We strongly encourage our users to configure a Maven
repository mirror closer to their location, please read {{{guides/
mini/guide-mirror-settings.html} How to Use Mirrors for
Repositories}}.
+ We strongly encorage our users to configure a Maven
repository mirror closer to their location, please read {{{guides/
mini/guide-mirror-settings.html} How to Use Mirrors for
Repositories}}.
*-+-+--+---+
| | Mirrors | Checksum | Signature |
Modified: maven/site/trunk/src/site/apt/download.apt.template
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/
download.apt.template?view=diffrev=517432r1=517431r2=517432
==
--- maven/site/trunk/src/site/apt/download.apt.template (original)
+++ maven/site/trunk/src/site/apt/download.apt.template Mon Mar 12
15:29:43 2007
@@ -16,7 +16,7 @@
Maven ${project.version} is distributed under the {{{http://
maven.apache.org/license.html} Apache License, version 2.0}}.
- We strongly encorage our users to configure a Maven
repository mirror closer to their location, please read {{{guides/
mini/guide-mirror-settings.html} How to Use Mirrors for
Repositories}}.
+ We strongly encourage our users to configure a Maven
repository mirror closer to their location, please read {{{guides/
mini/guide-mirror-settings.html} How to Use Mirrors for
Repositories}}.
*-+-+--+---+
| | Mirrors | Checksum | Signature |
Modified: maven/site/trunk/src/site/apt/insert-project-version.sh
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/
insert-project-version.sh?view=diffrev=517432r1=517431r2=517432
==
--- maven/site/trunk/src/site/apt/insert-project-version.sh (original)
+++ maven/site/trunk/src/site/apt/insert-project-version.sh Mon Mar
12 15:29:43 2007
@@ -4,5 +4,5 @@
for i in $files
do
- sed 's/${project.version}/2.0.5/' $i.template $i
+ sed 's/${project.version}/2.0.5/g' $i.template $i
done
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven classpath order
I wonder if this is an OS thing? I've heard that before, but when I experimented with dependency:build-classpath, it was always ordered the same. -Original Message- From: Jagan Padmanabha Pillai -X (jpadmana - Insight Solutions, Inc. at Cisco) [mailto:[EMAIL PROTECTED] Sent: Monday, March 12, 2007 7:11 PM To: Maven Developers List Subject: Maven classpath order Hi, I didn't get an answer from the maven users alias. Could someone here answer this. Maven classpath generation seems not to follow any order. Shouldn't it use the same order depedencies are mentioned in the pom file. Somewhere I read Maven 2.0.5 fixed this issue, but when I tested it doesn't seem to have fixed. Please let me know Thanks!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r517432 - in /maven/site/trunk/src/site/apt: download.apt download.apt.template insert-project-version.sh
On 12 Mar 07, at 3:31 PM 12 Mar 07, Brett Porter wrote:
should download.apt be removed from svn if it is generated?
Probably better to leave it there as people updating might forget to
generate it and deploy the site and then we'll end up with an empty
page. We can just nuke it when Velocity works in Doxia. Not the most
elegant of solutions but seeing as we forgot to update it from 2.0.3
(which is probably a year) it's better then having it out of date.
jason.
On 12/03/2007, at 3:29 PM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Mon Mar 12 15:29:43 2007
New Revision: 517432
URL: http://svn.apache.org/viewvc?view=revrev=517432
Log:
o fix the generation script and encourage is spelt like that
even in Americanese.
Modified:
maven/site/trunk/src/site/apt/download.apt
maven/site/trunk/src/site/apt/download.apt.template
maven/site/trunk/src/site/apt/insert-project-version.sh
Modified: maven/site/trunk/src/site/apt/download.apt
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/
download.apt?view=diffrev=517432r1=517431r2=517432
=
=
--- maven/site/trunk/src/site/apt/download.apt (original)
+++ maven/site/trunk/src/site/apt/download.apt Mon Mar 12 15:29:43
2007
@@ -16,7 +16,7 @@
Maven 2.0.5 is distributed under the {{{http://maven.apache.org/
license.html} Apache License, version 2.0}}.
- We strongly encourage our users to configure a Maven
repository mirror closer to their location, please read {{{guides/
mini/guide-mirror-settings.html} How to Use Mirrors for
Repositories}}.
+ We strongly encorage our users to configure a Maven
repository mirror closer to their location, please read {{{guides/
mini/guide-mirror-settings.html} How to Use Mirrors for
Repositories}}.
*-+-+--+---+
| | Mirrors | Checksum | Signature |
Modified: maven/site/trunk/src/site/apt/download.apt.template
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/
download.apt.template?view=diffrev=517432r1=517431r2=517432
=
=
--- maven/site/trunk/src/site/apt/download.apt.template (original)
+++ maven/site/trunk/src/site/apt/download.apt.template Mon Mar 12
15:29:43 2007
@@ -16,7 +16,7 @@
Maven ${project.version} is distributed under the {{{http://
maven.apache.org/license.html} Apache License, version 2.0}}.
- We strongly encorage our users to configure a Maven
repository mirror closer to their location, please read {{{guides/
mini/guide-mirror-settings.html} How to Use Mirrors for
Repositories}}.
+ We strongly encourage our users to configure a Maven
repository mirror closer to their location, please read {{{guides/
mini/guide-mirror-settings.html} How to Use Mirrors for
Repositories}}.
*-+-+--+---+
| | Mirrors | Checksum | Signature |
Modified: maven/site/trunk/src/site/apt/insert-project-version.sh
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/
insert-project-version.sh?view=diffrev=517432r1=517431r2=517432
=
=
--- maven/site/trunk/src/site/apt/insert-project-version.sh
(original)
+++ maven/site/trunk/src/site/apt/insert-project-version.sh Mon
Mar 12 15:29:43 2007
@@ -4,5 +4,5 @@
for i in $files
do
- sed 's/${project.version}/2.0.5/' $i.template $i
+ sed 's/${project.version}/2.0.5/g' $i.template $i
done
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r517432 - in /maven/site/trunk/src/site/apt: download.apt download.apt.template insert-project-version.sh
On 12/03/2007, at 4:03 PM, Jason van Zyl wrote: On 12 Mar 07, at 3:31 PM 12 Mar 07, Brett Porter wrote: should download.apt be removed from svn if it is generated? Probably better to leave it there as people updating might forget to generate it and deploy the site and then we'll end up with an empty page. We can just nuke it when Velocity works in Doxia. Not the most elegant of solutions but seeing as we forgot to update it from 2.0.3 (which is probably a year) it's better then having it out of date. Not sure what you mean: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/ download.apt?revision=393226view=markuppathrev=517432 lists 2.0.4 (and ignores 2.0.3 and 2.0.1 as they were both broken releases). The checked in page is already out of date - the one you checked in went from encourage - encorage (while the template went in the correct direction). If you prefer, I can remove the shell script and put an antrun in to do a filter replace instead so it's always right. Also, the current page seems to have *no* download of the ant tasks at all. Are we just denying their existence now? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven classpath order
Hi, I didn't get an answer from the maven users alias. Could someone here answer this. Maven classpath generation seems not to follow any order. Shouldn't it use the same order depedencies are mentioned in the pom file. Somewhere I read Maven 2.0.5 fixed this issue, but when I tested it doesn't seem to have fixed. Please let me know Thanks!!
Creating a central Maven repository for OSGi bundles
There are some initiatives like Apache Felix about repackaging libraries from the maven repository until projects themselves include the OSGi manifest. It makes sense in the meantime to have a Maven repo with same structure but with OSGi bundles. This repo would be temporal and things could change over the time until it's stable. There was already a temporal repo from eclipse installation in http://repo1.maven.org/eclipse/ Artifacts there can go into central with one change, bundle id = groupId + artifactId, meaning that they are going to be stored in the repo with different name than they are in the eclipse installation. eg. org.eclipse.equinox.common will be group=org.eclipse.equinox artifact=common About infrastructure, we'd need to know if maven.org has enough bandwidth to host it or we need to look for alternatives. I'm gonna run it also through [EMAIL PROTECTED] to see if we can have apache artifacts in apache machines and sync as we do with the usual maven repo. comments? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating a central Maven repository for OSGi bundles
Is this going to result in a copy of all the artifacts with added bundled metadata? Will the structure will be same? Just wondering if the bundles should just be included in the main repository with a classifier. - Brett On 12/03/2007, at 4:46 PM, Carlos Sanchez wrote: There are some initiatives like Apache Felix about repackaging libraries from the maven repository until projects themselves include the OSGi manifest. It makes sense in the meantime to have a Maven repo with same structure but with OSGi bundles. This repo would be temporal and things could change over the time until it's stable. There was already a temporal repo from eclipse installation in http://repo1.maven.org/eclipse/ Artifacts there can go into central with one change, bundle id = groupId + artifactId, meaning that they are going to be stored in the repo with different name than they are in the eclipse installation. eg. org.eclipse.equinox.common will be group=org.eclipse.equinox artifact=common About infrastructure, we'd need to know if maven.org has enough bandwidth to host it or we need to look for alternatives. I'm gonna run it also through [EMAIL PROTECTED] to see if we can have apache artifacts in apache machines and sync as we do with the usual maven repo. comments? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] maven-dependency-plugin 2.0-alpha-2
I'd like to release maven-dependency-plugin:2.0-alpha-2 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plug in-2.0-alpha-2/ Staged at: http://people.apache.org/~brianf/staging-repository Changes: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13137styleName =HtmlprojectId=11214Create=Create Release Notes - Maven 2.x Dependency Plugin - Version 2.0-alpha-2 - HTML format Bug * [MDEP-27] - Plugin configuration error message - caused by certain liefecycle bindings * [MDEP-56] - test-jar * [MDEP-58] - linux / mac unit test failures * [MDEP-60] - Multiple plugin execution sections not correctly executed * [MDEP-66] - Sources goal not implemented * [MDEP-67] - NPE when resolving the version of a dependency Improvement * [MDEP-55] - generate javadocs and jar src files with releae * [MDEP-57] - dependency:resolve should output scope * [MDEP-63] - allow version to be stripped from useSubfolderPerArtifact New Feature * [MDEP-26] - New goal to write classpath string with all dependencies from local repo * [MDEP-54] - Exclude and Include specific dependencies based on Artifact id or group name * [MDEP-65] - Copy dependencies in a Maven repository like layout Vote is open for 72 hours. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Test failures in maven-source-plugin
I'm seeing test failures in maven-source-plugin. Anyone else? On Windows w/ Maven 2.0.5: Failed tests: testProject003(org.apache.maven.plugin.source.SourceJarMojoTest) testProject007(org.apache.maven.plugin.source.SourceJarMojoTest) testProject004(org.apache.maven.plugin.source.TestSourceJarMojoTest) Tests run: 7, Failures: 3, Errors: 0, Skipped: 0 On Linux with an older version, Running org.apache.maven.plugin.source.SourceJarMojoTest Tests run: 4, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 15.439 sec FAILURE! Running org.apache.maven.plugin.source.TestSourceJarMojoTest Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 13.626 sec FAILURE! Results : Tests run: 7, Failures: 4, Errors: 0, Skipped: 0 -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Archiva proxies index pages?
Interesting... http://people.apache.org/~wsmoak/maven/archiva/r517480-proxying-index-page.jpg That's Archiva running on localhost, proxying central, and when I visit http://localhost:9091/archiva/repository/myrepo/org/apache/maven/plugins/maven-dependency-plugin I see the index page from central (note the Apache and OS version and hostname at the bottom.) Is that supposed to happen? -- Wendy
Re: Test failures in maven-source-plugin
Good day to you, Wendy, On Windows XP, Maven 2.0.5, maven-source-plugin -r517268 builds fine Cheers, Franz On 3/12/07, Wendy Smoak [EMAIL PROTECTED] wrote: I'm seeing test failures in maven-source-plugin. Anyone else? On Windows w/ Maven 2.0.5: Failed tests: testProject003(org.apache.maven.plugin.source.SourceJarMojoTest) testProject007(org.apache.maven.plugin.source.SourceJarMojoTest) testProject004(org.apache.maven.plugin.source.TestSourceJarMojoTest) Tests run: 7, Failures: 3, Errors: 0, Skipped: 0 On Linux with an older version, Running org.apache.maven.plugin.source.SourceJarMojoTest Tests run: 4, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 15.439 sec FAILURE! Running org.apache.maven.plugin.source.TestSourceJarMojoTest Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 13.626 sec FAILURE! Results : Tests run: 7, Failures: 4, Errors: 0, Skipped: 0 -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven code style - eclipse
http://maven.apache.org/developers/maven-eclipse-codestyle.xml seems to be out of date ( the throws, extend, etc do not split ) Do we have another official one? Thanks -D
Re: [VOTE] Release maven-plugin-tools 2.1 (take 2)
+1 On 10/03/2007, at 3:25 PM, Dennis Lundberg wrote: Hi, Trying this vote once more. This time with staging. This release is a preparation for a new release of the maven-plugin- plugin. Changes: - Add support for new annotations: @since for mojos and @implementation for parameters - Remove pluggy. It was only for the bootstrap and is no longer needed. Tag: http://svn.apache.org/repos/asf/maven/shared/tags/maven-plugin- tools-2.1/ Staged at: http://people.apache.org/~dennisl/staging-repository/ The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-model-converter 2.1 (take 2)
+1 On 10/03/2007, at 3:21 PM, Dennis Lundberg wrote: Hi, Trying this vote once more. This with staging. This release is a preparation for a release of the maven-one-plugin. The issues that have been resolved can be seen in JIRA: http://jira.codehaus.org/browse/MNG-2320 http://jira.codehaus.org/browse/MNG-2327 http://jira.codehaus.org/browse/MNG-2332 http://jira.codehaus.org/browse/MNG-2335 http://jira.codehaus.org/browse/MNG-2336 http://jira.codehaus.org/browse/MNG-2338 To summarize the changes, two types of plexus-components have been added: PluginRelocators and PluginConfigurationConverters. These help by converting plugin dependencies and their configuration. Tag: http://svn.apache.org/repos/asf/maven/shared/tags/maven-plugin- tools-2.1/ Staged at: http://people.apache.org/~dennisl/staging-repository/ The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
