Re: Putting projects in categories
On Tue, 2 Dec 2003 03:14 pm, Peter Donald wrote: > On Tue, 2 Dec 2003 03:04 pm, Jason van Zyl wrote: > > Vincent, > > > > How did you put a project in a specific category? I can't seem to find > > the option anywhere ... > > Go into admin screen and do a "viewProject" on each project. The top panel > has category at bottom of list. Just select maven and you be good to go. I just changed all the maven projects into maven category - or at least all the ones that I noticed. -- Cheers, Peter Donald "The ability to quote is a serviceable substitute for wit." -- Maugham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting projects in categories
On Tue, 2 Dec 2003 03:04 pm, Jason van Zyl wrote: > Vincent, > > How did you put a project in a specific category? I can't seem to find > the option anywhere ... Go into admin screen and do a "viewProject" on each project. The top panel has category at bottom of list. Just select maven and you be good to go. -- Cheers, Peter Donald Beer is proof that God loves us and wants us to be happy. -- Benjamin Franklin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] One JIRA project per plugin (was RE: [JIRA] maven-plugins project now exists)
On Sat, 15 Nov 2003 09:06 am, Vincent Massol wrote: > 2.5.1 is there! And I've already created a maven-plugins project. I've > put it in the Maven category. My question is whether we should *instead* > create a JIRA project per plugin and put all of them in the maven > category? +1 -- Cheers, Peter Donald "Monday is an awful way to spend 1/7th of your life." -Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-new
On Tue, 11 Nov 2003 01:05 am, Nicola Ken Barozzi wrote: > My personal understanding, in extreme summary, is that Peter Donald > refused to actively collaborate with some other Avalon members. I had > seen the fracture in the community and proposed him to make Phoenix a > project on par with Avalon; the Phoenix committers would have had access > to Avalon, but not vice versa. He refused. That is flat out lie as that is exactly what I wanted all along. -- Cheers, Peter Donald --- "Therefore it can be said that victorious warriors win first, and then go to battle, while defeated warriors go to battle first, and then seek to win." - Sun Tzu, the Art Of War --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving Plugins
On Thu, 9 Oct 2003 12:17 am, Florin Vancea wrote: > If I may say something before it's too late: Maybe there is a need for a > LATEST on each (or on several) branch (es). > > Something like > > > log4j > log4j > LATEST > > > should get the latest-and-gratest, but something like > > > log4j > log4j > 1.LATEST > > > should use the latest version available that still has the version with > prefix "1." > > Just a thought... I think it is a good throught but ... I think that it may be a beta idea to formalize a version-ing standard before you do this. For example one project may assume that anything compiled against 1.1 will work in 1.2 (ie minor versions represent forward compatible changes). Another project may assume that micro versions represent forward compatability (ie 1.1.2 is compatible with 1.1.1 or 1.1). That would make dependencys very close to JDK "optional packages"/"extensions" ala (except for no separation between implementation and specification). http://spice.sourceforge.net/extension/ http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html Alternatively you could specify version resolution scheme in the dependency declaration via something like log4j log4j 1.1 extension -- Cheers, Peter Donald *-* | "The only way to discover the limits of the | | possible is to go beyond them into the | |impossible." -Arthur C. Clarke | *-* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Code
On Thu, 25 Sep 2003 02:28 pm, [EMAIL PROTECTED] wrote: > Have you seen maven-fetch? Nope - a quick grep through the CVS didn't turn up anything and I haven't been subscribed to list for long. Want to point me at it ? TIA :) -- Cheers, Peter Donald Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. - Fred Brooks, Jr. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Code
On Thu, 25 Sep 2003 02:08 pm, Jason van Zyl wrote: > > I would like to use Mavens repository code in a few other applications. > > To do this what I would like to do is separate out the repository, > > fetching, verifying code into a separate component. > > Soon after 1.0 some components will be released for integration into the > general maven codebase. One of them specifically deals with artifact > handling and is meant to be a reusable in other applications. I assume > you want the exact same thing I'm looking for and that's integration > with a container :-) Sounds good. Can you point me at this - I am quite willing to do the work for you. I just prefer to tackle this earlier rather than later. -- Cheers, Peter Donald --- "You can't depend on your eyes when your imagination is out of focus." -Mark Twain --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Repository Code
Hi, I would like to use Mavens repository code in a few other applications. To do this what I would like to do is separate out the repository, fetching, verifying code into a separate component. I have had a look at the current codebase and what documentation I could find. ie http://wiki.codehaus.org/maven/ArtifactRepository http://wiki.codehaus.org/maven/IdGroupIdArtifactId http://wiki.codehaus.org/maven/ArtifactDownloading What I want to do is essentially grab what you have now and extend it in a few wierd and wonderful ways. Essentially what I want to do is enable alternative mechanisms for downloading remote artefacts. I also want to extend the mechanism via which artefacts are matched so that you can *optionally* support things like "request artefact version 1.1 and get reference to 1.1.1". This may not be used by Maven but is useful in other contexts. I want it to be extensively unit tested and will most likely develope it using TDD for the most part. However I expect that it will regularly be broken as I experiment with different techniques and designs. So I guess I was wondering how you want to me to do this. I would like maven to eventually use this once it stabilizes but in the meantime it is probably best it evolves independently. Would the best way to do this for me to just build it independently and then either donate it to maven at later stage or something? -- Cheers, Peter Donald --- "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -Albert Einstein --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moved Issues From Commons-Attributes Jira To Maven Jira
Hiya, I just noticed a whole bunch of Maven issues reported against the commons-attributes JIRA project. So I moved them across to Maven. Some of the issues are really old and have been fixed so I then closed them. However there are others that I dont know about and someone more knowledgable needs to go through and sort the good from the bad. Not subscribed to Maven-dev so just CC me if anything more needs to be done wrt these issues. -- Cheers, Peter Donald *---* | "You can't depend on your eyes when your | | imagination is out of focus." -Mark Twain | *---* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standard method for retrieving plugin properties in plugins
On Thu, 26 Jun 2003 12:07 pm, Jason van Zyl wrote: > > > so that would extract the 'maven.dest.dir' property from the xdoc plugin > and place the value in 'dest.dir' for use in the current context. Sounds good. But it may be better to name the attributes more according to what they do or else you would need to consult documentation to figure out which gets copied where. or maybe where : As that you could also extend this to allow setting of such properties like -- Cheers, Peter Donald | We shall not cease from exploration, and the | | end of all our exploring will be to arrive | | where we started and know the place for the | |first time -- T.S. Eliot | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Inheriting project properties and maven.xml
+1 :) I believe it already exists in beta-8 for maven.xml and is supposed to exist in beta-9 for proeprties (though I have not tried). I would also love to see inheritance of build.properties aswell ... ;) On Wed, 26 Mar 2003 21:34, [EMAIL PROTECTED] wrote: > Hi, > > I'd like to propose to support inheritance of project properties and > maven.xml. It would work in the following way: > > if the project POM extends a project.xml ( tag) > set inheritdir = location of inherited project.xml > if project.properites exist in inheritdir > load inheritdir/project.properties > fi > if maven.xml exists in inheritdir > load inheritdir/maven.xml > fi > fi > > What do you think? > > Thanks > -Vincent > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Peter Donald *--* The phrase "computer literate user" really means the person has been hurt so many times that the scar tissue is thick enough so he no longer feels the pain. -- Alan Cooper, The Inmates are Running the Asylum *--* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA bugs not going to the ML anymore?
On Thu, 20 Mar 2003 10:41, [EMAIL PROTECTED] wrote: > So is it time now for a Jira plugin for Maven so we can get the > bugs/issues etc as part of the docs? +10 ;) -- Cheers, Peter Donald --- "You can't depend on your eyes when your imagination is out of focus." -Mark Twain --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
