Re: calling vote for 2.0.5
Yep, I understand the intent and that is good. A reasonable interval(?) for micro releases should be fine. I'd be quite happy about more releases of Maven in its current state. However, what matters more, IMO, would be micro releases of the core plugins. Jochen -- How fast can a year go? As fast as your childs first year. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Collapse Maven permission groups
After the allotted 72 hours, the results stand as: Full proposal: 9 (7 PMC, 2 committers): Brett, Arnaud, Emmanuel, Trygve, Dennis, Fabrizio, Lukas, Rahul, Milos Partial proposal: 6 (6 PMC): Joakim, John T, Kenney, Jesse, John C, Jason Abstained: 3 (3 PMC): Mike, Vincent S, Stephane Against: None. Not yet voted: 3 PMC: Vincent M, Carlos, James This is in favour of the full proposal. I will follow up with the PMC about how we execute this. - Brett On 09/01/2007, at 10:50 AM, Brett Porter wrote: Hi, Since there was no objection to calling a vote, as discussed in the proposal, I'd like to call a vote on this. To see the proposal and discussion: http://mail-archives.apache.org/ mod_mbox/maven-dev/200612.mbox/%3c67FC84B5-4510-469B-AEC1- [EMAIL PROTECTED] Vote to operate as - requiring 2/3rds of the PMC to vote (13), with a majority within those votes for it to pass (ie, add them all and if the result is > 0). Other votes would be welcome with reasons as advisory, but not binding. - Votes can be changed at any time before result is posted. - Vote is open for at least 72 hours, completing once enough have voted after that. - There are two different +1 options. If there is a majority for "collapse all groups" against both other options, then it will pass. If it fails, then all votes will be transferred to the "retain subproject access restrictions" and recounted. The proposal is to collapse all access groups into a single ACL for Maven, with the following list of 37 committers: Fabrice Bellingard, David Blevins, John Casey, Maria Ching, Joakim Erdfelt, Dan Fabulich (pending), Brian Fox, Fabrizio Giustina, Arnaud Heritier, Jeff Jensen, Shinobu Kawai, Milos Kleint, Trygve Laugstol, Felipe Leme, Dennis Lundberg, Vincent Massol, Jesse McConnell, Stephane Nicoll, Mike Perham, Brett Porter, Edwin Punzalan, Daniel Rall, Allan Ramirez, Carlos Sanchez, Vincent Siveton, Wendy Smoak, Torbjorn Smorgrav, James Strachan, Chris Stevenson, Rahul Thakur, Lukas Theussl, John Tolentino, Dan Tran, Emmanuel Venisse, Kenney Westerhof, Andrew Williams, Henri Yandell, and Jason van Zyl. The alternate proposal is to retain subproject access restrictions, so the groups will be (PMC members removed, as they retain access to all areas): maven=wsmoak,felipeal,jjensen,shinobu,dlr,mkleint,handyande,epunzalan, aramirez,dantran,chrisjs,brianf,bellingard,oching (/maven-1,/ components,/plugins,/archetype,/core-integration-testing,/jxr,/ release,/skins,/resources,/release-testing) doxia=dblevins archiva=bayard,epunzalan,oching continuum=dblevins,rinku scm=dantran,smorgrav wagon= surefire= All of the above groups will have access to: /pom, /project, / site, /shared in this proposal, so it is essentially to collapse the @maven group, making the permission groups match the existence of a corresponding dev lists. [ ] +1 for the full proposal - collapse all groups (implies a vote for the next option if vote doesn't pass) [ ] +1 for the partial proposal - retain subproject access restrictions [ ] 0 abstain from vote [ ] -1 do not alter the current permissions Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M1] Status for modello / maven-model / m1-core
For a quick "opinion ASAP", I did a quick review of the pages, and they look pretty good. When I can review more in-depth, I may suggest some additional info/clarifications and writing changes on the site docs. My initial suggestion on the Overview page is that I would like a link to an example/real page of each of the potential items that it can generate to help the reader understand what they could get when using it. Of course, for starters, use the POM reference page as one. -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: Thursday, January 11, 2007 7:53 PM To: Maven Developers List Subject: Re: [M1] Status for modello / maven-model / m1-core ping ?? Sorry, but I would like to have your opinion ASAP. My holidays are ended at the end of this week and I want to finish as much tasks as possible before. Arnaud On 1/10/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > > Hi guys, > > Since some days I'm working on modello / maven-model / m1-core. > Here is the current status. If you have some comments ... feel free > > Modello > To resolve relative entities in the POM (to keep the compatibility > with maven 1.0.x) I had to update the STAX-RI plugin to add a new read > method (http://jira.codehaus.org/browse/MODELLO-77 > ) with a path as parameter (instead of a stream). > > Modello plugin for maven 1. > I updated the maven-modello-plugin for m1 to use the latest versions > of modello. > I also updated (created) a documentation for it : > http://maven.apache.org/maven-1.x/plugins/modello/ > If some of you can take some minutes to review it (my english > particularly ;-) ) > I'm not sure, but it could be possible when we'll release it to move > it out from the sandbox ? It could be a new plugin in the m1 > distribution, even if I'm not sure that it will have a lot of users > ;-) (Note that this is a really little plugin to maintain) > > Maven-model > I built the documentation from modello : > http://maven.apache.org/maven-1.x/reference/maven-model/3.0.2-SNAPSHOT > /maven.html > > The problem is that we manually updated the previous documentation > build from the model by Brett. > I propose that now we always use (as in m2) the documentation (and > the > site) generated by modello. > We'll update the model documentation if necessary. > We have to fix in the maven.mdo the documentation which was updated > in the generated xdoc and not in the real model. > I attached the patch which lists changes from the previous generation. > The problem is to merge changes in links and in some comments for m1. > In a modello model we can't have some notes for a given version of > the model ? > > I continue to test m1 with the new model which uses a stax > reader/writer. > > Arnaud > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
I don't think either of these are cases for 'package resources', but general lifecycle improvements (Which are in the 2.1 design wiki). Is that right? - Brett On 06/01/2007, at 7:47 AM, Aaron Digulla wrote: Brett Porter wrote: Can anyone think of a use case other than the war plugin, or should we just go with the pre-package phase? I have these use cases: - Filter or generate files for the site plugin (for example, extract information out of the sources for apt files) - Multi-Step source/unit test generation (XML -> XML -> Java and DB -> XML -> Java including filtering) Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://www.philmann-dark.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: continuum-store and JDO
Marcelo Fukushima wrote: On 1/11/07, Rahul Thakur <[EMAIL PROTECTED]> wrote: Marcelo Fukushima wrote: > yeah... > but now that ive settled it, ive encountered a new set of probs, this > time in the data-management with the trunk on svn: > -while backing up the continuum store, a FileWriter is used (wich uses > default system char encoding), but the stream used to write the xml > tries to use utf-8, in wich case an exception is thrown; This is a known issue. I think its to do with locale settings. ive attached a patch that i think solves this one (it actually uses the same charset encoding in the writer by using a OutputStreamWriter ( FileOutputStream, Charset ) i know this test passes to me now but itd be great if anyone else could test it in a diff env (maybe other jdks and os's) http://jira.codehaus.org/secure/ManageAttachments.jspa?id=45956 Thanks! I will take it for a spin (hopefully shortly) though i am on Windows XP as well. Yep, it might be a good idea if we can get it to run on another machine as well. > -the backup file (an xml) is compared to a hard coded xml file... but > at least with my dev env (win xp with jdk6), some child nodes are > swaped... You mean the nodes _do_ exist _but_ in a different order. Can you point me to the test that is showing this behaviour? exactly... ill generate it again, but i think the id tag gets switched... its in the DataManagementToolTest inside the continuum-data-management module Cool, will have a look when I get back home. I came across a different behaviour with HashMap key ordering in JDK 6. I suspect if its something similar in this case. btw i cant seen to compile from maven: it gives me an Access Denied Exception on some random directories (im compiling and running the tests from inside eclipse) Do you have continuum checkout on your drive's root or nested a few levels in another directory ? Rahul Cheers, Rahul > > the first one is most certainly a bug (and i already have a fix), > while the second one im not so sure so i wanted to ask yall first > > regards, > takeshi > > On 1/11/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: >> windows path length pb? >> >> Marcelo Fukushima a écrit : >> > im looking into it, but i cant seen to install the modules locally - >> > im getting a weird random access denied error... >> > >> > >> > On 1/10/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: >> >> Yes. A global patch would be better instead of separate patches. >> >> I tried your 2 patches and updated locally jpox-* to 1.1.3 in >> >> continuum parent pom. With them, all tests works fine, but continuum >> >> doesn't start. >> >> >> >> Emmanuel >> >> >> >> Marcelo Fukushima a écrit : >> >> > Hello dear devs. >> >> > >> >> > After everyone's help, ive noticed that jpox was saving the >> >> > BuildDefinition with wrong values (the buildFresh and arguments and >> >> > possibly others too)... since i dont know how jpox work, the first >> >> > thing i tried was to update to a more recent version of it (namely >> >> > 1.1.3) and everything worked fine... >> >> > im going to attach the test case to jira (actually a patch to the >> >> > testcase to check those things too), but should i attach a patch to >> >> > the pom too? >> >> > >> >> > On 1/9/07, Brett Porter <[EMAIL PROTECTED]> wrote: >> >> >> The metadata file (and enhanced classes) are generated when you >> use >> >> >> Maven to build the project. As long as eclipse doesn't >> overwrite the >> >> >> class files it should be fine. Alternatively, you can use the >> eclipse >> >> >> plugin for jpox to make sure the classes get enhanced and just run >> >> >> maven once to generate the metadata file. I've never used that >> >> >> plugin, but it is available from the jpox site. >> >> >> >> >> >> Thanks! >> >> >> - Brett >> >> >> >> >> >> On 09/01/2007, at 2:27 PM, Marcelo Fukushima wrote: >> >> >> >> >> >> > hello folks! i sent a couple of emails to the user list, but i >> >> guess i >> >> >> > could help a little too, right? so i just checked out the >> code from >> >> >> > SVN and wanted to tackle >> >> >> > http://jira.codehaus.org/browse/CONTINUUM-1103 >> >> >> > while i could isolate the bug (the property is not getting >> persisted >> >> >> > on the db) but since i know almost nothing about jdo, i cant >> run the >> >> >> > tests inside eclipse to try to figure out the solution and i >> couldnt >> >> >> > find where the metadata file or the enhanced version of the >> classes >> >> >> > are found... >> >> >> > is there any doc that can help me with that kinda of info? >> thanks >> >> >> > in advance >> >> >> > -- >> >> >> > []'s >> >> >> > Marcelo Takeshi Fukushima >> >> >> >> >> > >> >> > >> >> >> >> >> > >> > >> >> > >
[jira] Subscription: Design & Best Practices
Issue Subscription Filter: Design & Best Practices (37 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-2477Implement repository security improvements for verification of downloaded artifacts http://jira.codehaus.org/browse/MNG-2477 MNG-2642maven-archetype-webapp does not produce Standard Directory Layout http://jira.codehaus.org/browse/MNG-2642 MNG-1305Document Maven's own development process http://jira.codehaus.org/browse/MNG-1305 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-1936pattern: for mojo parameters which have default values in the POM we need standard usage http://jira.codehaus.org/browse/MNG-1936 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1634move maven-core-it to integration-tests http://jira.codehaus.org/browse/MNG-1634 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-1452best practices: deployment of aggregate JARs produced by the assembly plug-in http://jira.codehaus.org/browse/MNG-1452 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-939 specify maven settings from command line http://jira.codehaus.org/browse/MNG-939 MNG-139 server definitions should be reusable http://jira.codehaus.org/browse/MNG-139 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-905 review clean repo install of m2 for download trimming http://jira.codehaus.org/browse/MNG-905 MNG-140 refactor maven-artifact http://jira.codehaus.org/browse/MNG-140 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-1437How to make additions to the POM and have it be backward/forward compatible http://jira.codehaus.org/browse/MNG-1437 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-868 Use uniform format for and other tags http://jira.codehaus.org/browse/MNG-868 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: continuum-store and JDO
On 1/11/07, Rahul Thakur <[EMAIL PROTECTED]> wrote: Marcelo Fukushima wrote: > yeah... > but now that ive settled it, ive encountered a new set of probs, this > time in the data-management with the trunk on svn: > -while backing up the continuum store, a FileWriter is used (wich uses > default system char encoding), but the stream used to write the xml > tries to use utf-8, in wich case an exception is thrown; This is a known issue. I think its to do with locale settings. ive attached a patch that i think solves this one (it actually uses the same charset encoding in the writer by using a OutputStreamWriter ( FileOutputStream, Charset ) i know this test passes to me now but itd be great if anyone else could test it in a diff env (maybe other jdks and os's) http://jira.codehaus.org/secure/ManageAttachments.jspa?id=45956 > -the backup file (an xml) is compared to a hard coded xml file... but > at least with my dev env (win xp with jdk6), some child nodes are > swaped... You mean the nodes _do_ exist _but_ in a different order. Can you point me to the test that is showing this behaviour? exactly... ill generate it again, but i think the id tag gets switched... its in the DataManagementToolTest inside the continuum-data-management module btw i cant seen to compile from maven: it gives me an Access Denied Exception on some random directories (im compiling and running the tests from inside eclipse) Cheers, Rahul > > the first one is most certainly a bug (and i already have a fix), > while the second one im not so sure so i wanted to ask yall first > > regards, > takeshi > > On 1/11/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: >> windows path length pb? >> >> Marcelo Fukushima a écrit : >> > im looking into it, but i cant seen to install the modules locally - >> > im getting a weird random access denied error... >> > >> > >> > On 1/10/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: >> >> Yes. A global patch would be better instead of separate patches. >> >> I tried your 2 patches and updated locally jpox-* to 1.1.3 in >> >> continuum parent pom. With them, all tests works fine, but continuum >> >> doesn't start. >> >> >> >> Emmanuel >> >> >> >> Marcelo Fukushima a écrit : >> >> > Hello dear devs. >> >> > >> >> > After everyone's help, ive noticed that jpox was saving the >> >> > BuildDefinition with wrong values (the buildFresh and arguments and >> >> > possibly others too)... since i dont know how jpox work, the first >> >> > thing i tried was to update to a more recent version of it (namely >> >> > 1.1.3) and everything worked fine... >> >> > im going to attach the test case to jira (actually a patch to the >> >> > testcase to check those things too), but should i attach a patch to >> >> > the pom too? >> >> > >> >> > On 1/9/07, Brett Porter <[EMAIL PROTECTED]> wrote: >> >> >> The metadata file (and enhanced classes) are generated when you >> use >> >> >> Maven to build the project. As long as eclipse doesn't >> overwrite the >> >> >> class files it should be fine. Alternatively, you can use the >> eclipse >> >> >> plugin for jpox to make sure the classes get enhanced and just run >> >> >> maven once to generate the metadata file. I've never used that >> >> >> plugin, but it is available from the jpox site. >> >> >> >> >> >> Thanks! >> >> >> - Brett >> >> >> >> >> >> On 09/01/2007, at 2:27 PM, Marcelo Fukushima wrote: >> >> >> >> >> >> > hello folks! i sent a couple of emails to the user list, but i >> >> guess i >> >> >> > could help a little too, right? so i just checked out the >> code from >> >> >> > SVN and wanted to tackle >> >> >> > http://jira.codehaus.org/browse/CONTINUUM-1103 >> >> >> > while i could isolate the bug (the property is not getting >> persisted >> >> >> > on the db) but since i know almost nothing about jdo, i cant >> run the >> >> >> > tests inside eclipse to try to figure out the solution and i >> couldnt >> >> >> > find where the metadata file or the enhanced version of the >> classes >> >> >> > are found... >> >> >> > is there any doc that can help me with that kinda of info? >> thanks >> >> >> > in advance >> >> >> > -- >> >> >> > []'s >> >> >> > Marcelo Takeshi Fukushima >> >> >> >> >> > >> >> > >> >> >> >> >> > >> > >> >> > > -- []'s Marcelo Takeshi Fukushima
Re: [M1] Status for modello / maven-model / m1-core
ping ?? Sorry, but I would like to have your opinion ASAP. My holidays are ended at the end of this week and I want to finish as much tasks as possible before. Arnaud On 1/10/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: Hi guys, Since some days I'm working on modello / maven-model / m1-core. Here is the current status. If you have some comments ... feel free Modello To resolve relative entities in the POM (to keep the compatibility with maven 1.0.x) I had to update the STAX-RI plugin to add a new read method (http://jira.codehaus.org/browse/MODELLO-77 ) with a path as parameter (instead of a stream). Modello plugin for maven 1. I updated the maven-modello-plugin for m1 to use the latest versions of modello. I also updated (created) a documentation for it : http://maven.apache.org/maven-1.x/plugins/modello/ If some of you can take some minutes to review it (my english particularly ;-) ) I'm not sure, but it could be possible when we'll release it to move it out from the sandbox ? It could be a new plugin in the m1 distribution, even if I'm not sure that it will have a lot of users ;-) (Note that this is a really little plugin to maintain) Maven-model I built the documentation from modello : http://maven.apache.org/maven-1.x/reference/maven-model/3.0.2-SNAPSHOT/maven.html The problem is that we manually updated the previous documentation build from the model by Brett. I propose that now we always use (as in m2) the documentation (and the site) generated by modello. We'll update the model documentation if necessary. We have to fix in the maven.mdo the documentation which was updated in the generated xdoc and not in the real model. I attached the patch which lists changes from the previous generation. The problem is to merge changes in links and in some comments for m1. In a modello model we can't have some notes for a given version of the model ? I continue to test m1 with the new model which uses a stax reader/writer. Arnaud
Re: continuum-store and JDO
Marcelo Fukushima wrote: yeah... but now that ive settled it, ive encountered a new set of probs, this time in the data-management with the trunk on svn: -while backing up the continuum store, a FileWriter is used (wich uses default system char encoding), but the stream used to write the xml tries to use utf-8, in wich case an exception is thrown; This is a known issue. I think its to do with locale settings. -the backup file (an xml) is compared to a hard coded xml file... but at least with my dev env (win xp with jdk6), some child nodes are swaped... You mean the nodes _do_ exist _but_ in a different order. Can you point me to the test that is showing this behaviour? Cheers, Rahul the first one is most certainly a bug (and i already have a fix), while the second one im not so sure so i wanted to ask yall first regards, takeshi On 1/11/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: windows path length pb? Marcelo Fukushima a écrit : > im looking into it, but i cant seen to install the modules locally - > im getting a weird random access denied error... > > > On 1/10/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: >> Yes. A global patch would be better instead of separate patches. >> I tried your 2 patches and updated locally jpox-* to 1.1.3 in >> continuum parent pom. With them, all tests works fine, but continuum >> doesn't start. >> >> Emmanuel >> >> Marcelo Fukushima a écrit : >> > Hello dear devs. >> > >> > After everyone's help, ive noticed that jpox was saving the >> > BuildDefinition with wrong values (the buildFresh and arguments and >> > possibly others too)... since i dont know how jpox work, the first >> > thing i tried was to update to a more recent version of it (namely >> > 1.1.3) and everything worked fine... >> > im going to attach the test case to jira (actually a patch to the >> > testcase to check those things too), but should i attach a patch to >> > the pom too? >> > >> > On 1/9/07, Brett Porter <[EMAIL PROTECTED]> wrote: >> >> The metadata file (and enhanced classes) are generated when you use >> >> Maven to build the project. As long as eclipse doesn't overwrite the >> >> class files it should be fine. Alternatively, you can use the eclipse >> >> plugin for jpox to make sure the classes get enhanced and just run >> >> maven once to generate the metadata file. I've never used that >> >> plugin, but it is available from the jpox site. >> >> >> >> Thanks! >> >> - Brett >> >> >> >> On 09/01/2007, at 2:27 PM, Marcelo Fukushima wrote: >> >> >> >> > hello folks! i sent a couple of emails to the user list, but i >> guess i >> >> > could help a little too, right? so i just checked out the code from >> >> > SVN and wanted to tackle >> >> > http://jira.codehaus.org/browse/CONTINUUM-1103 >> >> > while i could isolate the bug (the property is not getting persisted >> >> > on the db) but since i know almost nothing about jdo, i cant run the >> >> > tests inside eclipse to try to figure out the solution and i couldnt >> >> > find where the metadata file or the enhanced version of the classes >> >> > are found... >> >> > is there any doc that can help me with that kinda of info? thanks >> >> > in advance >> >> > -- >> >> > []'s >> >> > Marcelo Takeshi Fukushima >> >> >> > >> > >> >> > >
Re: [m1] Problem to build maven-model in continuum
It's now fixed Thx to kenney. I didn't see the problem of version with the jdk. I deployed modello jars after building them with a jdk 1.5. The build failed on maven.zones which uses a jdk 1.4 Arnaud On 1/10/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: Hi guys (and Jason particularly), I just added maven-model in continuum 1.0.3 to build it and it fails with a plexus error http://maven.zones.apache.org:8180/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=55&id=9 I don't have this problem when I build it with m1 itself. Can it be a problem with plexus because it is also used in continuum ? Arnaud
Re: continuum-store and JDO
yeah... but now that ive settled it, ive encountered a new set of probs, this time in the data-management with the trunk on svn: -while backing up the continuum store, a FileWriter is used (wich uses default system char encoding), but the stream used to write the xml tries to use utf-8, in wich case an exception is thrown; -the backup file (an xml) is compared to a hard coded xml file... but at least with my dev env (win xp with jdk6), some child nodes are swaped... the first one is most certainly a bug (and i already have a fix), while the second one im not so sure so i wanted to ask yall first regards, takeshi On 1/11/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: windows path length pb? Marcelo Fukushima a écrit : > im looking into it, but i cant seen to install the modules locally - > im getting a weird random access denied error... > > > On 1/10/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: >> Yes. A global patch would be better instead of separate patches. >> I tried your 2 patches and updated locally jpox-* to 1.1.3 in >> continuum parent pom. With them, all tests works fine, but continuum >> doesn't start. >> >> Emmanuel >> >> Marcelo Fukushima a écrit : >> > Hello dear devs. >> > >> > After everyone's help, ive noticed that jpox was saving the >> > BuildDefinition with wrong values (the buildFresh and arguments and >> > possibly others too)... since i dont know how jpox work, the first >> > thing i tried was to update to a more recent version of it (namely >> > 1.1.3) and everything worked fine... >> > im going to attach the test case to jira (actually a patch to the >> > testcase to check those things too), but should i attach a patch to >> > the pom too? >> > >> > On 1/9/07, Brett Porter <[EMAIL PROTECTED]> wrote: >> >> The metadata file (and enhanced classes) are generated when you use >> >> Maven to build the project. As long as eclipse doesn't overwrite the >> >> class files it should be fine. Alternatively, you can use the eclipse >> >> plugin for jpox to make sure the classes get enhanced and just run >> >> maven once to generate the metadata file. I've never used that >> >> plugin, but it is available from the jpox site. >> >> >> >> Thanks! >> >> - Brett >> >> >> >> On 09/01/2007, at 2:27 PM, Marcelo Fukushima wrote: >> >> >> >> > hello folks! i sent a couple of emails to the user list, but i >> guess i >> >> > could help a little too, right? so i just checked out the code from >> >> > SVN and wanted to tackle >> >> > http://jira.codehaus.org/browse/CONTINUUM-1103 >> >> > while i could isolate the bug (the property is not getting persisted >> >> > on the db) but since i know almost nothing about jdo, i cant run the >> >> > tests inside eclipse to try to figure out the solution and i couldnt >> >> > find where the metadata file or the enhanced version of the classes >> >> > are found... >> >> > is there any doc that can help me with that kinda of info? thanks >> >> > in advance >> >> > -- >> >> > []'s >> >> > Marcelo Takeshi Fukushima >> >> >> > >> > >> >> > > -- []'s Marcelo Takeshi Fukushima
Re: Maven 1.0.2
Sure, that sounds fair :-) jason. On 11 Jan 07, at 6:38 PM 11 Jan 07, Arnaud HERITIER wrote: With the new main page for the maven 2 site, I think that it is difficult to find the m1 site link (in the bottom left). Can't we add it with continuum and archiva in the box "other maven projects" ? WDYT ? Arnaud -- Forwarded message -- From: Murugan <[EMAIL PROTECTED]> Date: Jan 11, 2007 11:41 AM Subject: Maven 1.0.2 To: users@maven.apache.org Hi All... I want MAven 1.0.2 version. I visit the maven site but the require version page is outdated ,so where i download. Thx in advance With regards Murugan -- View this message in context: http://www.nabble.com/Maven-1.0.2-tf2958062s177.html#a8275174 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.0.2
Ok, I'll do it asap. Arnaud On 1/12/07, Brett Porter <[EMAIL PROTECTED]> wrote: yep On 12/01/2007, at 10:38 AM, Arnaud HERITIER wrote: > With the new main page for the maven 2 site, I think that it is > difficult to > find the m1 site link (in the bottom left). > Can't we add it with continuum and archiva in the box "other maven > projects" > ? > > WDYT ? > > Arnaud > > -- Forwarded message -- > From: Murugan <[EMAIL PROTECTED]> > Date: Jan 11, 2007 11:41 AM > Subject: Maven 1.0.2 > To: users@maven.apache.org > > > Hi All... > > I want MAven 1.0.2 version. I visit the maven site but the require > version page is outdated ,so where i download. > > > Thx in advance > > > With regards > > Murugan > -- > View this message in context: > http://www.nabble.com/Maven-1.0.2-tf2958062s177.html#a8275174 > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.0.2
yep On 12/01/2007, at 10:38 AM, Arnaud HERITIER wrote: With the new main page for the maven 2 site, I think that it is difficult to find the m1 site link (in the bottom left). Can't we add it with continuum and archiva in the box "other maven projects" ? WDYT ? Arnaud -- Forwarded message -- From: Murugan <[EMAIL PROTECTED]> Date: Jan 11, 2007 11:41 AM Subject: Maven 1.0.2 To: users@maven.apache.org Hi All... I want MAven 1.0.2 version. I visit the maven site but the require version page is outdated ,so where i download. Thx in advance With regards Murugan -- View this message in context: http://www.nabble.com/Maven-1.0.2-tf2958062s177.html#a8275174 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Reports
Jason van Zyl wrote: > > On 11 Jan 07, at 3:42 PM 11 Jan 07, robert burrell donkin wrote: > >> On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: >>> Hi Everyone, >> >> hi john >> >>> You can now generate release reports using the maven-swizzle-plugin. >> >> have you implemented your header checked yet? >> >> i'm interested in collaborating on release auditing (in particular >> for apache) >> > > Joakim has scanning tools, and Jochen actually made a RAT plugin over > at Mojo. I would make a plexus component of it I it were to be > integrated. > > Jason. See https://svn.apache.org/repos/asf/maven/sandbox/plugins/maven-license-plugin/ It has a functional scanner, and a mostly complete injection (only missing java source type). You'll want https://svn.apache.org/repos/asf/maven/sandbox/maven-shared-license/ also. I started down the path of making a generic java source parser module at https://svn.apache.org/repos/asf/maven/sandbox/maven-shared-java-parser/ but I ran out of time. When I get more time I'll get back to it, or someone else can take over where I left off. - Joakim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Maven 1.0.2
With the new main page for the maven 2 site, I think that it is difficult to find the m1 site link (in the bottom left). Can't we add it with continuum and archiva in the box "other maven projects" ? WDYT ? Arnaud -- Forwarded message -- From: Murugan <[EMAIL PROTECTED]> Date: Jan 11, 2007 11:41 AM Subject: Maven 1.0.2 To: users@maven.apache.org Hi All... I want MAven 1.0.2 version. I visit the maven site but the require version page is outdated ,so where i download. Thx in advance With regards Murugan -- View this message in context: http://www.nabble.com/Maven-1.0.2-tf2958062s177.html#a8275174 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
On 11 Jan 07, at 6:04 PM 11 Jan 07, Kenney Westerhof wrote: I totally agree. On that note I have put the one in that I promised for Ralph, and there is probably one more that I will attempt. So if anyone knows of a couple they are up for slot them in there. I pushed all 2.0.x issues to a version called 2.0.x to be the pool of unscheduled 2.0.x fixes. So things go to the specific versions from there. I did the same for 2.1.x and 2.2.x. So if you have time to fix anything in the next two weeks, say, slot it into 2.0.6. I will take another pass through JIRA this weekend. Jason. This 'micro release' is a rather big bugfix release. If you have lots of bugfix (micro) releases, and you stumble across a bug, it's pretty easy to find if it's solved by looking at the release notes. That is, if you update frequently. If you don't, you got lots of bugfix releasenotes to check, just as people will have to when deciding to upgrade to 2.0.5. So this way it's the users choice/fault/responsibility: * update often - less work to check if a bug has been fixed * update rarely - more entries to check, just as it is now (2.0.5: 90 issues) It's also easier to downgrade if you find a new showstopper, since you won't loose as much improvements as you would now. Brian E. Fox wrote: I agree with Jason on this. My initial reaction was "Weekly No way I can keep all my developers in synch." Then I realized that just because a build comes out doesn't mean we have to take it. As long as the plan is clear about what is fixed then it isn't a huge problem. I might take 2.0.5 simply because it's been so long, but after that I would probably wait until some compelling reason came along to update or after some period of time to avoid becoming stale. With the whole voting, vetting process, I'm not sure weekly will be manageable, biweekly seems more realistic, but I just don't see that more frequent releases really hurts anyone. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, January 11, 2007 1:32 PM To: Maven Developers List Subject: Re: calling vote for 2.0.5 On 11 Jan 07, at 1:16 PM 11 Jan 07, Rahul Thakur wrote: +1 for releasing 2.0.5 +0 for micro releases. I agree with Trygve's comment that too frequent of these can lead to inconsistent developer environments. Really the point is to schedule them and make the roadmaps available so that people can take them if they choose. If I had a team I probably wouldn't grab a micro release every week, but I might take one monthly or take one that had a fix in it I needed. I wouldn't expect people to consume them constantly, I just want to make the fixes available more frequently in an official form so people can use them. Jason. Cheers, Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, January 11, 2007 11:20 AM Subject: calling vote for 2.0.5 Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mai
Re: calling vote for 2.0.5
I totally agree. This 'micro release' is a rather big bugfix release. If you have lots of bugfix (micro) releases, and you stumble across a bug, it's pretty easy to find if it's solved by looking at the release notes. That is, if you update frequently. If you don't, you got lots of bugfix releasenotes to check, just as people will have to when deciding to upgrade to 2.0.5. So this way it's the users choice/fault/responsibility: * update often - less work to check if a bug has been fixed * update rarely - more entries to check, just as it is now (2.0.5: 90 issues) It's also easier to downgrade if you find a new showstopper, since you won't loose as much improvements as you would now. Brian E. Fox wrote: I agree with Jason on this. My initial reaction was "Weekly No way I can keep all my developers in synch." Then I realized that just because a build comes out doesn't mean we have to take it. As long as the plan is clear about what is fixed then it isn't a huge problem. I might take 2.0.5 simply because it's been so long, but after that I would probably wait until some compelling reason came along to update or after some period of time to avoid becoming stale. With the whole voting, vetting process, I'm not sure weekly will be manageable, biweekly seems more realistic, but I just don't see that more frequent releases really hurts anyone. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, January 11, 2007 1:32 PM To: Maven Developers List Subject: Re: calling vote for 2.0.5 On 11 Jan 07, at 1:16 PM 11 Jan 07, Rahul Thakur wrote: +1 for releasing 2.0.5 +0 for micro releases. I agree with Trygve's comment that too frequent of these can lead to inconsistent developer environments. Really the point is to schedule them and make the roadmaps available so that people can take them if they choose. If I had a team I probably wouldn't grab a micro release every week, but I might take one monthly or take one that had a fix in it I needed. I wouldn't expect people to consume them constantly, I just want to make the fixes available more frequently in an official form so people can use them. Jason. Cheers, Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, January 11, 2007 11:20 AM Subject: calling vote for 2.0.5 Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-script-ant 2.0.5
Scratch that, a cut/paste got away on me. Jason. On 11 Jan 07, at 5:21 PM 11 Jan 07, Jason van Zyl wrote: I need to release maven-script-ant 2.0.5 before releasing maven 2.0.5 Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Reports
On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: Hi Robert, Can you have a plexus component for the license header auditing then? i think so but we may need to think about the best way to do it... RAT's half way through a redesign ATM but i'll move that onto a branch :-/ I can hook it up to the plugin when it's ready. Only two information are needed: - check result (a boolean value) and this is conceptually difficult since the easiest and most obvious test (checking for headers in every file) will not work correctly for many projects at apache would need to be pluggable so that the rules can be refined easily - output file where the reports can link to the output is now a subject-predicate-object meta-data stream which is then converted to xml. RAT application uses a stylesheet to convert this to plain text. take your pick :-) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] release maven-script-ant 2.0.5
I need to release maven-script-ant 2.0.5 before releasing maven 2.0.5 Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Reports
On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: Was thinking of integrating both docck and rat plugins by calling their execute() methods. Docck throws a MojoFailureException when documentation tests fails and test results could be redirected to a file through the output parameter. So integration with this plugin is straightforward. Although the results of rat-maven-plugin can be redirected to a file, I don't see the same behavior when test failures are encountered. I'll talk to Jochen if we could apply the same behavior to his plugin. there are conceptual issues with this approach with RAT ATM RAT was developed as a pure reporting tool requiring manual analysis of the results. the problem is that there's a lot fuzziness both about some of the heuristics that RAT uses and about the legitimacy of some constructions. people are now more interested in using RAT as a regular report but this means more work before it'll work well. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Reports
Hi Robert, Can you have a plexus component for the license header auditing then? I can hook it up to the plugin when it's ready. Only two information are needed: - check result (a boolean value) and - output file where the reports can link to Thanks, John On 1/12/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: > Not yet. Still looking for existing maven plugins that might be doing > this already. Not sure if the verifier plugin could do this for us. there's quite a few wrinkles to release auditing which aren't immediately obvious RAT code's rubbish (i hacked it to automate checking of incubator releases) but i've learnt a lot about what a tool needs to be able to do. > I'm sure everyone would be happy to have new people to help out. perhaps too many around here know me too well to be too excited ;-) - robert - 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 site plugin webapp to another plugin
+1 I'd rather download only what I need. I have 512Kpbs (max). Other people here in Asia have slower connections because of the recent earthquake--fiber optic cables were cut if you haven't heard the news yet. On 1/12/07, Brett Porter <[EMAIL PROTECTED]> wrote: On 12/01/2007, at 1:14 AM, Kenney Westerhof wrote: > I imagine most developers have at least a 2Mbit > downlink You have quite an imagination :) I recently upgraded back up to a 1.5Mbit connection from 512Kbit. It's the highest I can get in my region, and usually is significantly more expensive. I expect there are developers in less prosperous places that don't have even that luxury. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
Jason van Zyl wrote: On 11 Jan 07, at 1:16 PM 11 Jan 07, Rahul Thakur wrote: +1 for releasing 2.0.5 +0 for micro releases. I agree with Trygve's comment that too frequent of these can lead to inconsistent developer environments. Really the point is to schedule them and make the roadmaps available so that people can take them if they choose. Yep, I understand the intent and that is good. A reasonable interval(?) for micro releases should be fine. If I had a team I probably wouldn't grab a micro release every week, but I might take one monthly or take one that had a fix in it I needed. Yes, you do have a team (teams even) ! ;-) Rahul I wouldn't expect people to consume them constantly, I just want to make the fixes available more frequently in an official form so people can use them. Jason. Cheers, Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, January 11, 2007 11:20 AM Subject: calling vote for 2.0.5 Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: continuum-store and JDO
windows path length pb? Marcelo Fukushima a écrit : im looking into it, but i cant seen to install the modules locally - im getting a weird random access denied error... On 1/10/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: Yes. A global patch would be better instead of separate patches. I tried your 2 patches and updated locally jpox-* to 1.1.3 in continuum parent pom. With them, all tests works fine, but continuum doesn't start. Emmanuel Marcelo Fukushima a écrit : > Hello dear devs. > > After everyone's help, ive noticed that jpox was saving the > BuildDefinition with wrong values (the buildFresh and arguments and > possibly others too)... since i dont know how jpox work, the first > thing i tried was to update to a more recent version of it (namely > 1.1.3) and everything worked fine... > im going to attach the test case to jira (actually a patch to the > testcase to check those things too), but should i attach a patch to > the pom too? > > On 1/9/07, Brett Porter <[EMAIL PROTECTED]> wrote: >> The metadata file (and enhanced classes) are generated when you use >> Maven to build the project. As long as eclipse doesn't overwrite the >> class files it should be fine. Alternatively, you can use the eclipse >> plugin for jpox to make sure the classes get enhanced and just run >> maven once to generate the metadata file. I've never used that >> plugin, but it is available from the jpox site. >> >> Thanks! >> - Brett >> >> On 09/01/2007, at 2:27 PM, Marcelo Fukushima wrote: >> >> > hello folks! i sent a couple of emails to the user list, but i guess i >> > could help a little too, right? so i just checked out the code from >> > SVN and wanted to tackle >> > http://jira.codehaus.org/browse/CONTINUUM-1103 >> > while i could isolate the bug (the property is not getting persisted >> > on the db) but since i know almost nothing about jdo, i cant run the >> > tests inside eclipse to try to figure out the solution and i couldnt >> > find where the metadata file or the enhanced version of the classes >> > are found... >> > is there any doc that can help me with that kinda of info? thanks >> > in advance >> > -- >> > []'s >> > Marcelo Takeshi Fukushima >> > >
Re: Moving site plugin webapp to another plugin
[X] 0 - Don't care. This is one case where I'd like to be able to alias a goal to a new plugin, or dual-alias the goal prefix. I agree the webapp belongs in a different plugin, and probably should have started it that way, but I really prefer to use "site:run". If it does get moved, and we can't do such aliasing, then I'd like site:run to be replaced with a call to invoke "mvn site-runner:run" or whatever it is, with a big deprecation message. I think I like Kenney's suggestion with an alternate name: turn the webapp bit into "site:war" (which requires no dependencies), and then use the jetty plugin to run it. - Brett On 11/01/2007, at 3:49 PM, Jason van Zyl wrote: Can we put the webapp stuff that's currently in the site plugin in another plugin so that when you simply want to generate your site you don't drag down Jetty and all its dependencies? It really is something unexpected and isn't something most would associate with just generating a site. The functionality is cool, I just think it belong in another plugin. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Reports
On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: Not yet. Still looking for existing maven plugins that might be doing this already. Not sure if the verifier plugin could do this for us. there's quite a few wrinkles to release auditing which aren't immediately obvious RAT code's rubbish (i hacked it to automate checking of incubator releases) but i've learnt a lot about what a tool needs to be able to do. I'm sure everyone would be happy to have new people to help out. perhaps too many around here know me too well to be too excited ;-) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Reports
It appears he'll stick with mojo. But couldn't speak for him. I'll update everyone when I get a patch and have him take a look at it. On 1/12/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: On 1/11/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 11 Jan 07, at 3:42 PM 11 Jan 07, robert burrell donkin wrote: > > > On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: > >> Hi Everyone, > > > > hi john > > > >> You can now generate release reports using the maven-swizzle-plugin. > > > > have you implemented your header checked yet? > > > > i'm interested in collaborating on release auditing (in particular > > for apache) > > > > Joakim has scanning tools, and Jochen actually made a RAT plugin over > at Mojo. I would make a plexus component of it I it were to be > integrated. jochen's looking for a new home for that plugin ATM - robert - 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 site plugin webapp to another plugin
On 12/01/2007, at 1:14 AM, Kenney Westerhof wrote: I imagine most developers have at least a 2Mbit downlink You have quite an imagination :) I recently upgraded back up to a 1.5Mbit connection from 512Kbit. It's the highest I can get in my region, and usually is significantly more expensive. I expect there are developers in less prosperous places that don't have even that luxury. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Reports
On 1/11/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: On 11 Jan 07, at 3:42 PM 11 Jan 07, robert burrell donkin wrote: > On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: >> Hi Everyone, > > hi john > >> You can now generate release reports using the maven-swizzle-plugin. > > have you implemented your header checked yet? > > i'm interested in collaborating on release auditing (in particular > for apache) > Joakim has scanning tools, and Jochen actually made a RAT plugin over at Mojo. I would make a plexus component of it I it were to be integrated. jochen's looking for a new home for that plugin ATM - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Reports
Was thinking of integrating both docck and rat plugins by calling their execute() methods. Docck throws a MojoFailureException when documentation tests fails and test results could be redirected to a file through the output parameter. So integration with this plugin is straightforward. Although the results of rat-maven-plugin can be redirected to a file, I don't see the same behavior when test failures are encountered. I'll talk to Jochen if we could apply the same behavior to his plugin. On 1/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: On 11 Jan 07, at 3:42 PM 11 Jan 07, robert burrell donkin wrote: > On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: >> Hi Everyone, > > hi john > >> You can now generate release reports using the maven-swizzle-plugin. > > have you implemented your header checked yet? > > i'm interested in collaborating on release auditing (in particular > for apache) > Joakim has scanning tools, and Jochen actually made a RAT plugin over at Mojo. I would make a plexus component of it I it were to be integrated. Jason. > - robert > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-ear-plugin 2.3.1
+1 On 1/11/07, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: +1 fabrizio On 1/8/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote: > Hi, > > I'd like to release the ear plugin which contains a backward > compatibility issue in 2.3 [1]. The issue has been fixed and the > reporter has validated his builds successfully. > > Revision 492264 > > Snapshot available > http://people.apache.org/~snicoll/maven-stage-repo/org/apache/maven/plugins/maven-ear-plugin/2.3.1-SNAPSHOT/ > > Votes open for 72h. > > My +1, > > Stéphane > > > [1] http://jira.codehaus.org/browse/MEAR-53 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Release Reports
On 11 Jan 07, at 3:42 PM 11 Jan 07, robert burrell donkin wrote: On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: Hi Everyone, hi john You can now generate release reports using the maven-swizzle-plugin. have you implemented your header checked yet? i'm interested in collaborating on release auditing (in particular for apache) Joakim has scanning tools, and Jochen actually made a RAT plugin over at Mojo. I would make a plexus component of it I it were to be integrated. Jason. - robert - 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: Release Reports
Not yet. Still looking for existing maven plugins that might be doing this already. Not sure if the verifier plugin could do this for us. I'm sure everyone would be happy to have new people to help out. On 1/12/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: > Hi Everyone, hi john > You can now generate release reports using the maven-swizzle-plugin. have you implemented your header checked yet? i'm interested in collaborating on release auditing (in particular for apache) - robert - 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: Release Reports
On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: Hi Everyone, hi john You can now generate release reports using the maven-swizzle-plugin. have you implemented your header checked yet? i'm interested in collaborating on release auditing (in particular for apache) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Reports
By the way, for this example, the changes I made to
maven-source-plugin's POM to generate the report is:
[...]
maven-swizzle-plugin
MPSOURCE
RELEASE
${basedir}/src/site/xdoc/release-report.xml
495351
true
docck-successful.txt
false
license-failed.txt
scm:svn:http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-source-plugin
http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-source-plugin/2.0.2-SNAPSHOT/
http://maven.apache.org/plugins/maven-source-plugin/
On 1/12/07, John Tolentino <[EMAIL PROTECTED]> wrote:
Here's the example report:
http://people.apache.org/~jtolentino/staging_site/maven-swizzle-plugin/release-report.html
On 1/12/07, Mike Perham <[EMAIL PROTECTED]> wrote:
> John, can you give us a sample of what the final report looks like?
>
> On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote:
> > Hi Everyone,
> >
> > You can now generate release reports using the maven-swizzle-plugin.
> > Here's the related documentation:
> >
> >
http://people.apache.org/~jtolentino/staging_site/maven-swizzle-plugin/examples/generating-release-report.html
> >
> > This is an implementation on what's discussed in this thread:
> >
> >
http://www.nabble.com/Feedback-Needed-on-Release-Reporting-Tool-tf2843851s177.html
> >
> > Thanks,
> > John
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Reports
Here's the example report: http://people.apache.org/~jtolentino/staging_site/maven-swizzle-plugin/release-report.html On 1/12/07, Mike Perham <[EMAIL PROTECTED]> wrote: John, can you give us a sample of what the final report looks like? On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: > Hi Everyone, > > You can now generate release reports using the maven-swizzle-plugin. > Here's the related documentation: > > http://people.apache.org/~jtolentino/staging_site/maven-swizzle-plugin/examples/generating-release-report.html > > This is an implementation on what's discussed in this thread: > > http://www.nabble.com/Feedback-Needed-on-Release-Reporting-Tool-tf2843851s177.html > > Thanks, > John > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Reports
John, can you give us a sample of what the final report looks like? On 1/11/07, John Tolentino <[EMAIL PROTECTED]> wrote: Hi Everyone, You can now generate release reports using the maven-swizzle-plugin. Here's the related documentation: http://people.apache.org/~jtolentino/staging_site/maven-swizzle-plugin/examples/generating-release-report.html This is an implementation on what's discussed in this thread: http://www.nabble.com/Feedback-Needed-on-Release-Reporting-Tool-tf2843851s177.html Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using the -J option with javac
i think I got it, i'll use Xmx and Xms only when forking On 1/11/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: MCOMPILER-22 has a problem as the javac compiler is being called with -J for Xmx and Xms and from the docs [1] it's not accepted in argument files. We're gonna use always argument files when forking, can the -J option be removed ? [1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javac.html -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release Reports
Hi Everyone, You can now generate release reports using the maven-swizzle-plugin. Here's the related documentation: http://people.apache.org/~jtolentino/staging_site/maven-swizzle-plugin/examples/generating-release-report.html This is an implementation on what's discussed in this thread: http://www.nabble.com/Feedback-Needed-on-Release-Reporting-Tool-tf2843851s177.html Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using the -J option with javac
MCOMPILER-22 has a problem as the javac compiler is being called with -J for Xmx and Xms and from the docs [1] it's not accepted in argument files. We're gonna use always argument files when forking, can the -J option be removed ? [1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javac.html -- 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: calling vote for 2.0.5
Regardless of these process issues, I should add that I'm all for getting a release out. Congrats to the team on feeling things are stable enough to go out and thanks for all the hard work put into other areas of the project. Brian On Jan 11, 2007, at 9:30 AM, Brian Topping wrote: I'm in a similar situation with patches I've provided. Some have integration tests as well, as requested. No comments have been made on any of the patches, they are months old. They might not seem important, but we had to throw away our entire Maven investment at a company I am at, after months of work to get it integrated and create these patches when problems developed. A primary reason for it's demise was people didn't like using forked builds of Maven just so they could get their daily work done. [-1]. The process should be updated so patches are either rejected with corrective measures or given a "fix version" where they will be applied. Brian On Jan 11, 2007, at 2:04 AM, Franz Fehringer wrote: Hello, WAGONHTTP-6 and MNG-2066 are already resolved; the fixes only need to be incorporated in the 2.0.5 (or 2.0.6) release. MNG-2305 should then also be resolved. Greetings Franz Tom Huybrechts schrieb: Can't you "solve" this with -Dhttps.proxyHost=xxx - Dhttps.proxyPort=... ? On 1/11/07, Franz Fehringer <[EMAIL PROTECTED]> wrote: Will this release contain solutions to MNG-2305 MNG-2066 WAGONHTTP-6 ? These issues mean, that it is impossible to access HTTPS (SSL) repositories from behind proxies/firewalls (i.e. from corporate networks). Thanks and greetings Franz Jason van Zyl schrieb: > Hi, > > I want to call a vote for 2.0.5. All the issues that are going to get > done are done. We'll release and move on. > > I would like to start building all releases from a standard machine > with the same JDK. I would like to propose the maven.org machine which > is monitored 24/7 running Linux. It serves as the central repository > but can easily handle a few builds. They can be built from that > machine and deployed to Apache. I think this is far better then each > of us building stuff from our own machines and deploying. > > Otherwise everything for 2.0.5 is ready to go. > > I will also chop up what's in JIRA into some smaller versions as I > think some micro releases for improvements and smaller changes is > better then waiting 7 months for another release. If we schedule them > out them people can decide whether they want to upgrade or not. But I > know there are several things I would like to get in and I know that > Mike/Ralph would like to get in MNG-1577 which we can squeeze into a > 2.0.6 in a week or two. These are micro release. > > Jason. > > --- -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: calling vote for 2.0.5
I agree with Jason on this. My initial reaction was "Weekly No way I can keep all my developers in synch." Then I realized that just because a build comes out doesn't mean we have to take it. As long as the plan is clear about what is fixed then it isn't a huge problem. I might take 2.0.5 simply because it's been so long, but after that I would probably wait until some compelling reason came along to update or after some period of time to avoid becoming stale. With the whole voting, vetting process, I'm not sure weekly will be manageable, biweekly seems more realistic, but I just don't see that more frequent releases really hurts anyone. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, January 11, 2007 1:32 PM To: Maven Developers List Subject: Re: calling vote for 2.0.5 On 11 Jan 07, at 1:16 PM 11 Jan 07, Rahul Thakur wrote: > +1 for releasing 2.0.5 > > +0 for micro releases. I agree with Trygve's comment that too > frequent of these can lead to inconsistent developer environments. > Really the point is to schedule them and make the roadmaps available so that people can take them if they choose. If I had a team I probably wouldn't grab a micro release every week, but I might take one monthly or take one that had a fix in it I needed. I wouldn't expect people to consume them constantly, I just want to make the fixes available more frequently in an official form so people can use them. Jason. > Cheers, > Rahul > > > - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> > To: "Maven Developers List" > Sent: Thursday, January 11, 2007 11:20 AM > Subject: calling vote for 2.0.5 > > >> Hi, >> >> I want to call a vote for 2.0.5. All the issues that are going to >> get done are done. We'll release and move on. >> >> I would like to start building all releases from a standard >> machine with the same JDK. I would like to propose the maven.org >> machine which is monitored 24/7 running Linux. It serves as the >> central repository but can easily handle a few builds. They can be >> built from that machine and deployed to Apache. I think this is >> far better then each of us building stuff from our own machines >> and deploying. >> >> Otherwise everything for 2.0.5 is ready to go. >> >> I will also chop up what's in JIRA into some smaller versions as I >> think some micro releases for improvements and smaller changes is >> better then waiting 7 months for another release. If we schedule >> them out them people can decide whether they want to upgrade or >> not. But I know there are several things I would like to get in >> and I know that Mike/Ralph would like to get in MNG-1577 which we >> can squeeze into a 2.0.6 in a week or two. These are micro release. >> >> Jason. >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
On 11 Jan 07, at 1:16 PM 11 Jan 07, Rahul Thakur wrote: +1 for releasing 2.0.5 +0 for micro releases. I agree with Trygve's comment that too frequent of these can lead to inconsistent developer environments. Really the point is to schedule them and make the roadmaps available so that people can take them if they choose. If I had a team I probably wouldn't grab a micro release every week, but I might take one monthly or take one that had a fix in it I needed. I wouldn't expect people to consume them constantly, I just want to make the fixes available more frequently in an official form so people can use them. Jason. Cheers, Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, January 11, 2007 11:20 AM Subject: calling vote for 2.0.5 Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
+1 for releasing 2.0.5 +0 for micro releases. I agree with Trygve's comment that too frequent of these can lead to inconsistent developer environments. Cheers, Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, January 11, 2007 11:20 AM Subject: calling vote for 2.0.5 Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
+1 from me. For practical purposes, we can control a single environment much more easily (eg. removing the local repository before we build a release, or making sure it's built on JDK 1.4) than N developer boxes. Even if the builds are 100% reproducible, it's not a bad idea to have a clean environment for staging releases, so development artifacts/code/environment/etc. don't get in the way. -j On 1/10/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
I'm in a similar situation with patches I've provided. Some have integration tests as well, as requested. No comments have been made on any of the patches, they are months old. They might not seem important, but we had to throw away our entire Maven investment at a company I am at, after months of work to get it integrated and create these patches when problems developed. A primary reason for it's demise was people didn't like using forked builds of Maven just so they could get their daily work done. [-1]. The process should be updated so patches are either rejected with corrective measures or given a "fix version" where they will be applied. Brian On Jan 11, 2007, at 2:04 AM, Franz Fehringer wrote: Hello, WAGONHTTP-6 and MNG-2066 are already resolved; the fixes only need to be incorporated in the 2.0.5 (or 2.0.6) release. MNG-2305 should then also be resolved. Greetings Franz Tom Huybrechts schrieb: Can't you "solve" this with -Dhttps.proxyHost=xxx - Dhttps.proxyPort=... ? On 1/11/07, Franz Fehringer <[EMAIL PROTECTED]> wrote: Will this release contain solutions to MNG-2305 MNG-2066 WAGONHTTP-6 ? These issues mean, that it is impossible to access HTTPS (SSL) repositories from behind proxies/firewalls (i.e. from corporate networks). Thanks and greetings Franz Jason van Zyl schrieb: > Hi, > > I want to call a vote for 2.0.5. All the issues that are going to get > done are done. We'll release and move on. > > I would like to start building all releases from a standard machine > with the same JDK. I would like to propose the maven.org machine which > is monitored 24/7 running Linux. It serves as the central repository > but can easily handle a few builds. They can be built from that > machine and deployed to Apache. I think this is far better then each > of us building stuff from our own machines and deploying. > > Otherwise everything for 2.0.5 is ready to go. > > I will also chop up what's in JIRA into some smaller versions as I > think some micro releases for improvements and smaller changes is > better then waiting 7 months for another release. If we schedule them > out them people can decide whether they want to upgrade or not. But I > know there are several things I would like to get in and I know that > Mike/Ralph would like to get in MNG-1577 which we can squeeze into a > 2.0.6 in a week or two. These are micro release. > > Jason. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Collapse Maven permission groups
On 8 Jan 07, at 7:04 PM 8 Jan 07, Jason van Zyl wrote: -1 I change mine to: [X ] +1 for the partial proposal - retain subproject access restrictions I just want at the sub-project level. On 8 Jan 07, at 6:50 PM 8 Jan 07, Brett Porter wrote: Hi, Since there was no objection to calling a vote, as discussed in the proposal, I'd like to call a vote on this. To see the proposal and discussion: http://mail- archives.apache.org/mod_mbox/maven-dev/200612.mbox/% [EMAIL PROTECTED] Vote to operate as - requiring 2/3rds of the PMC to vote (13), with a majority within those votes for it to pass (ie, add them all and if the result is > 0). Other votes would be welcome with reasons as advisory, but not binding. - Votes can be changed at any time before result is posted. - Vote is open for at least 72 hours, completing once enough have voted after that. - There are two different +1 options. If there is a majority for "collapse all groups" against both other options, then it will pass. If it fails, then all votes will be transferred to the "retain subproject access restrictions" and recounted. The proposal is to collapse all access groups into a single ACL for Maven, with the following list of 37 committers: Fabrice Bellingard, David Blevins, John Casey, Maria Ching, Joakim Erdfelt, Dan Fabulich (pending), Brian Fox, Fabrizio Giustina, Arnaud Heritier, Jeff Jensen, Shinobu Kawai, Milos Kleint, Trygve Laugstol, Felipe Leme, Dennis Lundberg, Vincent Massol, Jesse McConnell, Stephane Nicoll, Mike Perham, Brett Porter, Edwin Punzalan, Daniel Rall, Allan Ramirez, Carlos Sanchez, Vincent Siveton, Wendy Smoak, Torbjorn Smorgrav, James Strachan, Chris Stevenson, Rahul Thakur, Lukas Theussl, John Tolentino, Dan Tran, Emmanuel Venisse, Kenney Westerhof, Andrew Williams, Henri Yandell, and Jason van Zyl. The alternate proposal is to retain subproject access restrictions, so the groups will be (PMC members removed, as they retain access to all areas): maven=wsmoak,felipeal,jjensen,shinobu,dlr,mkleint,handyande,epunzalan ,aramirez,dantran,chrisjs,brianf,bellingard,oching (/maven-1,/ components,/plugins,/archetype,/core-integration-testing,/jxr,/ release,/skins,/resources,/release-testing) doxia=dblevins archiva=bayard,epunzalan,oching continuum=dblevins,rinku scm=dantran,smorgrav wagon= surefire= All of the above groups will have access to: /pom, /project, / site, /shared in this proposal, so it is essentially to collapse the @maven group, making the permission groups match the existence of a corresponding dev lists. [ ] +1 for the full proposal - collapse all groups (implies a vote for the next option if vote doesn't pass) [ ] 0 abstain from vote [ ] -1 do not alter the current permissions Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Collapse Maven permission groups
-0 it might be nice to have access to everything once you join, but it seems handy to have an acl of all those writing to the various areas. On 8 Jan 2007, at 23:50, Brett Porter wrote: Hi, Since there was no objection to calling a vote, as discussed in the proposal, I'd like to call a vote on this. To see the proposal and discussion: http://mail-archives.apache.org/ mod_mbox/maven-dev/200612.mbox/%3c67FC84B5-4510-469B-AEC1- [EMAIL PROTECTED] Vote to operate as - requiring 2/3rds of the PMC to vote (13), with a majority within those votes for it to pass (ie, add them all and if the result is > 0). Other votes would be welcome with reasons as advisory, but not binding. - Votes can be changed at any time before result is posted. - Vote is open for at least 72 hours, completing once enough have voted after that. - There are two different +1 options. If there is a majority for "collapse all groups" against both other options, then it will pass. If it fails, then all votes will be transferred to the "retain subproject access restrictions" and recounted. The proposal is to collapse all access groups into a single ACL for Maven, with the following list of 37 committers: Fabrice Bellingard, David Blevins, John Casey, Maria Ching, Joakim Erdfelt, Dan Fabulich (pending), Brian Fox, Fabrizio Giustina, Arnaud Heritier, Jeff Jensen, Shinobu Kawai, Milos Kleint, Trygve Laugstol, Felipe Leme, Dennis Lundberg, Vincent Massol, Jesse McConnell, Stephane Nicoll, Mike Perham, Brett Porter, Edwin Punzalan, Daniel Rall, Allan Ramirez, Carlos Sanchez, Vincent Siveton, Wendy Smoak, Torbjorn Smorgrav, James Strachan, Chris Stevenson, Rahul Thakur, Lukas Theussl, John Tolentino, Dan Tran, Emmanuel Venisse, Kenney Westerhof, Andrew Williams, Henri Yandell, and Jason van Zyl. The alternate proposal is to retain subproject access restrictions, so the groups will be (PMC members removed, as they retain access to all areas): maven=wsmoak,felipeal,jjensen,shinobu,dlr,mkleint,handyande,epunzalan, aramirez,dantran,chrisjs,brianf,bellingard,oching (/maven-1,/ components,/plugins,/archetype,/core-integration-testing,/jxr,/ release,/skins,/resources,/release-testing) doxia=dblevins archiva=bayard,epunzalan,oching continuum=dblevins,rinku scm=dantran,smorgrav wagon= surefire= All of the above groups will have access to: /pom, /project, / site, /shared in this proposal, so it is essentially to collapse the @maven group, making the permission groups match the existence of a corresponding dev lists. [ ] +1 for the full proposal - collapse all groups (implies a vote for the next option if vote doesn't pass) [ ] +1 for the partial proposal - retain subproject access restrictions [ ] 0 abstain from vote [ ] -1 do not alter the current permissions Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r485976 - /maven/plugins/trunk/pom.xml
I have a parent pom that defines the SCM of itself and all it's children by
using
scm:svn:http://${scm.host}/svnrepos/${object.namespace}/${artifactId}/trunk
and I end up with
scm:svn:http://${scm.host}/svnrepos/${object.namespace
}/${artifactId}/trunk/${artifactId}
I'm not sure if this is still going on with more recent updates, but
currently when I do a help:effective-pom, the SCM URL has the artifactId
appended.
Clearly this is sub-optimal. Maven shouldn't invisibly append things to my
configuration (assuming it actually IS doing this, of course).
Can someone tell me where this happens and how to prevent it?
> The way we deploy plugin sites today does not include the version
> number in the path. If this is going to change I'd like to see a
> vote about it on the dev list first. The url should be:
>
> scp://people.apache.org/www/maven.apache.org/plugins/$
> {pom.artifactId}/
Actually, it should be what it originally was. Neither of these will
work due to the automatic appending of the artifact ID.
Joakim - please roll back.
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I'm just an unfrozen caveman software developer. I don't understand your
strange, "modern" ways.
Re: Moving site plugin webapp to another plugin
+1 On 11 Jan 2007, at 04:49, Jason van Zyl wrote: Can we put the webapp stuff that's currently in the site plugin in another plugin so that when you simply want to generate your site you don't drag down Jetty and all its dependencies? It really is something unexpected and isn't something most would associate with just generating a site. The functionality is cool, I just think it belong in another plugin. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
+1 Andy On 10 Jan 2007, at 22:20, Jason van Zyl wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
+1 -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 1/11/07, Tom Huybrechts <[EMAIL PROTECTED]> wrote: Can't you "solve" this with -Dhttps.proxyHost=xxx -Dhttps.proxyPort=... ? On 1/11/07, Franz Fehringer <[EMAIL PROTECTED]> wrote: > Will this release contain solutions to > > MNG-2305 > MNG-2066 > WAGONHTTP-6 > > ? > > These issues mean, that it is impossible to access HTTPS (SSL) > repositories from behind proxies/firewalls (i.e. from corporate networks). > > Thanks and greetings > > Franz > > > Jason van Zyl schrieb: > > Hi, > > > > I want to call a vote for 2.0.5. All the issues that are going to get > > done are done. We'll release and move on. > > > > I would like to start building all releases from a standard machine > > with the same JDK. I would like to propose the maven.org machine which > > is monitored 24/7 running Linux. It serves as the central repository > > but can easily handle a few builds. They can be built from that > > machine and deployed to Apache. I think this is far better then each > > of us building stuff from our own machines and deploying. > > > > Otherwise everything for 2.0.5 is ready to go. > > > > I will also chop up what's in JIRA into some smaller versions as I > > think some micro releases for improvements and smaller changes is > > better then waiting 7 months for another release. If we schedule them > > out them people can decide whether they want to upgrade or not. But I > > know there are several things I would like to get in and I know that > > Mike/Ralph would like to get in MNG-1577 which we can squeeze into a > > 2.0.6 in a week or two. These are micro release. > > > > Jason. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: calling vote for 2.0.5
+1 Dan -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Thursday, January 11, 2007 4:24 AM To: Maven Developers List Subject: Re: calling vote for 2.0.5 Agree to the plan. Emmanuel Jason van Zyl a écrit : > Hi, > > I want to call a vote for 2.0.5. All the issues that are going to get > done are done. We'll release and move on. > > I would like to start building all releases from a standard machine > with the same JDK. I would like to propose the maven.org machine which > is monitored 24/7 running Linux. It serves as the central repository > but can easily handle a few builds. They can be built from that > machine and deployed to Apache. I think this is far better then each > of us building stuff from our own machines and deploying. > > Otherwise everything for 2.0.5 is ready to go. > > I will also chop up what's in JIRA into some smaller versions as I > think some micro releases for improvements and smaller changes is > better then waiting 7 months for another release. If we schedule them > out them people can decide whether they want to upgrade or not. But I > know there are several things I would like to get in and I know that > Mike/Ralph would like to get in MNG-1577 which we can squeeze into a > 2.0.6 in a week or two. These are micro release. > > Jason. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > > > -- This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving site plugin webapp to another plugin
On 11/01/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Yes, following that logic why don't we just stick all the plugins in one in one plugin and not bother trying to separate concerns at all. Then we'll only have one plugin and when people run "mvn clean" they will just get everything they need? uberplugin.. sounds like a good candidate for mojo.codehaus :) I have watched bewildered users run "mvn site" and ask why all of god's green earth is being downloaded and it makes Maven unpleasant to use. Can't see it being much of a barrier for entry - I would have thought most Maven users would be used to seeing many seemingly random libraries being downloaded the first time they execute a new goal. The site:site and site:run goals are closely related and I would expect them to be provided by the same plugin. Maybe per-goal dependencies would be the way to go. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving site plugin webapp to another plugin
On 11 Jan 07, at 9:20 AM 11 Jan 07, Mark Hobson wrote: Besides, all good developers have jetty in their local repo already ;) Yes, following that logic why don't we just stick all the plugins in one in one plugin and not bother trying to separate concerns at all. Then we'll only have one plugin and when people run "mvn clean" they will just get everything they need? I have watched bewildered users run "mvn site" and ask why all of god's green earth is being downloaded and it makes Maven unpleasant to use. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving site plugin webapp to another plugin
On 11 Jan 07, at 9:14 AM 11 Jan 07, Kenney Westerhof wrote:
-0
More plugins are bad IMHO.
I don't think so especially when it encourages a separation of
concerns. Publishing a site should not require a servlet container.
We could either remove that functionality
and just let people site:state jetty:run '-Dwar=${site.directory}'
or, in the future, make those deps scoped optional and specify
which ones are used for what mojo so that when you run that mojo
they won't be optional anymore.
jetty: 452kb
servlet-api: 139kb
jetty-util: 66kb
It's way more then that. It triggers pulling down the dependency
plugin, the ant run plugin. All its dependencies. From a clean
repository I've seen it take quite some time to pull everything down.
Jason.
-
0.6 MB
doxia-site-renderer:32kb
doxia-core:208kb
oro:65kb
plexus-velocity: 8kb
velocity: 388kb
velocity-dep: 694kb
doxia-decoration-model: 41kb
--
1.4 MB
so removing jetty will only remove 30% from the deps needed
specifically
for the site plugin. I imagine most developers have at least a 2Mbit
downlink, so this would reduce their build time 3 seconds, only once
(for me and all people with an intranet proxy it would decrease the
build time by about 60 milliseconds).
I think this is nothing compared to the size of all of maven's plugins
and dependencies (50+ MB or so?).
In short: why bother? :)
-- Kenney
Emmanuel Venisse wrote:
+1
Emmanuel
Jason van Zyl a écrit :
Can we put the webapp stuff that's currently in the site plugin
in another plugin so that when you simply want to generate your
site you don't drag down Jetty and all its dependencies? It
really is something unexpected and isn't something most would
associate with just generating a site. The functionality is cool,
I just think it belong in another plugin.
Jason.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: calling vote for 2.0.5
Good Idea (tm) Jason. I'm glad you are making a "production release environment". -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, January 11, 2007 8:42 AM To: Maven Developers List Subject: Re: calling vote for 2.0.5 On 11 Jan 07, at 8:56 AM 11 Jan 07, Kenney Westerhof wrote: > I really don't care what machine builds the release. > Maven is supposed to be able to make reproducible builds so it > shouldn't > matter where you build from. > You know as well as I do that isn't the case quite yet. The reduction of any variation is necessary. > The only problem will be the contents of the local repository > (snapshots), > which will be a problem on any machine. > No. What JVM is that is used, what version of Maven you used to build it as well, how you bootstrapped. All these things need to be defined so that things can be as consistent as possible. > I suppose you're going to do an 2.0.5-rc-1 with mvn > release:prepare, which > should make sure only non-snapshot project artifacts are used > (but not plugins). The only way to be sure no snapshot plugins are > used > is to disable the snapshot repo from the parent/root pom.. I'm going to use the staging tools and put the release as it will be in final form into a repository which won't pollute the central repository. If it's fine then I will merge it with the central repository. > > Maybe I'm missing the point - what's far better about performing > releases > on a 27/4 monitored box running Linux that also hosts the central > repo? > Do you want to release from a Windows machine? I don't. And if many people take responsibility for doing releases, which should happen, then it should happen with the same set of parameters off the same machine. If something goes wrong with that machine we get a 5 minute turn around time for help which is a good thing. No one in an enterprise environment lets joe developer build a release for production (unless they are insane) and we shouldn't either. The releases should come from an environment that is as stable as possible. Jason. > -- Kenney > > Jason van Zyl wrote: >> I haven't called the vote yet, just wanted to settle on picking a >> machine to dispatch it from. >> It's coming, it's coming :-) >> jason. >> On 10 Jan 07, at 5:20 PM 10 Jan 07, Jason van Zyl wrote: >>> Hi, >>> >>> I want to call a vote for 2.0.5. All the issues that are going to >>> get done are done. We'll release and move on. >>> >>> I would like to start building all releases from a standard >>> machine with the same JDK. I would like to propose the maven.org >>> machine which is monitored 24/7 running Linux. It serves as the >>> central repository but can easily handle a few builds. They can >>> be built from that machine and deployed to Apache. I think this >>> is far better then each of us building stuff from our own >>> machines and deploying. >>> >>> Otherwise everything for 2.0.5 is ready to go. >>> >>> I will also chop up what's in JIRA into some smaller versions as >>> I think some micro releases for improvements and smaller changes >>> is better then waiting 7 months for another release. If we >>> schedule them out them people can decide whether they want to >>> upgrade or not. But I know there are several things I would like >>> to get in and I know that Mike/Ralph would like to get in >>> MNG-1577 which we can squeeze into a 2.0.6 in a week or two. >>> These are micro release. >>> >>> Jason. >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
On 11 Jan 07, at 8:56 AM 11 Jan 07, Kenney Westerhof wrote: I really don't care what machine builds the release. Maven is supposed to be able to make reproducible builds so it shouldn't matter where you build from. You know as well as I do that isn't the case quite yet. The reduction of any variation is necessary. The only problem will be the contents of the local repository (snapshots), which will be a problem on any machine. No. What JVM is that is used, what version of Maven you used to build it as well, how you bootstrapped. All these things need to be defined so that things can be as consistent as possible. I suppose you're going to do an 2.0.5-rc-1 with mvn release:prepare, which should make sure only non-snapshot project artifacts are used (but not plugins). The only way to be sure no snapshot plugins are used is to disable the snapshot repo from the parent/root pom.. I'm going to use the staging tools and put the release as it will be in final form into a repository which won't pollute the central repository. If it's fine then I will merge it with the central repository. Maybe I'm missing the point - what's far better about performing releases on a 27/4 monitored box running Linux that also hosts the central repo? Do you want to release from a Windows machine? I don't. And if many people take responsibility for doing releases, which should happen, then it should happen with the same set of parameters off the same machine. If something goes wrong with that machine we get a 5 minute turn around time for help which is a good thing. No one in an enterprise environment lets joe developer build a release for production (unless they are insane) and we shouldn't either. The releases should come from an environment that is as stable as possible. Jason. -- Kenney Jason van Zyl wrote: I haven't called the vote yet, just wanted to settle on picking a machine to dispatch it from. It's coming, it's coming :-) jason. On 10 Jan 07, at 5:20 PM 10 Jan 07, Jason van Zyl wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jboss client jars and maven
Hi, this is actually a user question and should be asked on the user list. There are also more people out there that use JBoss and maven so you may have better luck there. In the mean time I suggest you try to find out what it is that's breaking it. Take the maven2 built jar, unjar it, and try each step in turn to see if that solves it: - jar it up with the commandline 'jar' or ant; maybe the compression is unknown? - remove META-INF/maven/ - remove META-INF/MANIFEST.MF's Build-JDK entry - remove/change other manifest entries - remove META-INF/ - do a diff on the classes (perhaps using javap's output) - are the class versions different? Is the same jdk used for both maven and ant? - (is the content other than META-INF exactly the same? no missing classes?) -- Kenney Graham Leggett wrote: Hi all, I am have a very strange interoperability problem between jars produced by maven and jars produced by ant when it comes to JBoss. JBoss supports the concept of java code running standalone accessing EJBs in a JBoss container over a network. To do this you package up two files into the META-INF directory of a jar file - application-client.xml and jboss-client.xml - and deploy this client jar within your ear file to your JBoss server. We have an existing ant generated client jar that works fine in the ear file. When we swap it with the same jar built by maven, Jboss refuses to load the EJBs from the ear file, and behaves in a generally broken way, but not enough to give us a real error message. Swap the ant created jar back, and all returns back to normal. All other jars, from dependencies to the ejb and ear file, are built using maven, and these work fine on condition the ant built client jar is included. The differences between the ant jar and the maven jar come down to the entries inside MANIFEST.MF. The ant build has Ant-Version and Created-By, while the maven version has Archiver-Version, Created-By, Built-By and Build-JDK. The maven jar also has a "maven" directory containing the pom file. I don't yet know enough about all of this to reliably ascertain whether this is a JBoss problem or a maven problem, my question is - has anyone seen behaviour like this before? Could the different attributes inside the MANIFEST.FM file affect things? Could the presence of the "maven" directory and the copy of the pom file in the jar upset JBoss in any way? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving site plugin webapp to another plugin
On 11/01/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote: In short: why bother? :) I tend to agree with Kenney. Besides, all good developers have jetty in their local repo already ;) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving site plugin webapp to another plugin
-0
More plugins are bad IMHO. We could either remove that functionality
and just let people site:state jetty:run '-Dwar=${site.directory}'
or, in the future, make those deps scoped optional and specify
which ones are used for what mojo so that when you run that mojo
they won't be optional anymore.
jetty: 452kb
servlet-api: 139kb
jetty-util: 66kb
-
0.6 MB
doxia-site-renderer:32kb
doxia-core:208kb
oro:65kb
plexus-velocity: 8kb
velocity: 388kb
velocity-dep: 694kb
doxia-decoration-model: 41kb
--
1.4 MB
so removing jetty will only remove 30% from the deps needed specifically
for the site plugin. I imagine most developers have at least a 2Mbit
downlink, so this would reduce their build time 3 seconds, only once
(for me and all people with an intranet proxy it would decrease the build
time by about 60 milliseconds).
I think this is nothing compared to the size of all of maven's plugins
and dependencies (50+ MB or so?).
In short: why bother? :)
-- Kenney
Emmanuel Venisse wrote:
+1
Emmanuel
Jason van Zyl a écrit :
Can we put the webapp stuff that's currently in the site plugin in
another plugin so that when you simply want to generate your site you
don't drag down Jetty and all its dependencies? It really is something
unexpected and isn't something most would associate with just
generating a site. The functionality is cool, I just think it belong
in another plugin.
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: calling vote for 2.0.5
I really don't care what machine builds the release. Maven is supposed to be able to make reproducible builds so it shouldn't matter where you build from. The only problem will be the contents of the local repository (snapshots), which will be a problem on any machine. I suppose you're going to do an 2.0.5-rc-1 with mvn release:prepare, which should make sure only non-snapshot project artifacts are used (but not plugins). The only way to be sure no snapshot plugins are used is to disable the snapshot repo from the parent/root pom.. Maybe I'm missing the point - what's far better about performing releases on a 27/4 monitored box running Linux that also hosts the central repo? -- Kenney Jason van Zyl wrote: I haven't called the vote yet, just wanted to settle on picking a machine to dispatch it from. It's coming, it's coming :-) jason. On 10 Jan 07, at 5:20 PM 10 Jan 07, Jason van Zyl wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-war-plugin v2.0.2 in jira
On 11 Jan 07, at 3:21 AM 11 Jan 07, Tomasz Pik wrote: Hi, It looks that version 2.0.2 of maven-war-plugin is not marked as relesed in jira so changes are not visible in changelog - they are in roadmap. Can somebody take care about this? Done. Thanks, Tomek - 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]
Jboss client jars and maven
Hi all, I am have a very strange interoperability problem between jars produced by maven and jars produced by ant when it comes to JBoss. JBoss supports the concept of java code running standalone accessing EJBs in a JBoss container over a network. To do this you package up two files into the META-INF directory of a jar file - application-client.xml and jboss-client.xml - and deploy this client jar within your ear file to your JBoss server. We have an existing ant generated client jar that works fine in the ear file. When we swap it with the same jar built by maven, Jboss refuses to load the EJBs from the ear file, and behaves in a generally broken way, but not enough to give us a real error message. Swap the ant created jar back, and all returns back to normal. All other jars, from dependencies to the ejb and ear file, are built using maven, and these work fine on condition the ant built client jar is included. The differences between the ant jar and the maven jar come down to the entries inside MANIFEST.MF. The ant build has Ant-Version and Created-By, while the maven version has Archiver-Version, Created-By, Built-By and Build-JDK. The maven jar also has a "maven" directory containing the pom file. I don't yet know enough about all of this to reliably ascertain whether this is a JBoss problem or a maven problem, my question is - has anyone seen behaviour like this before? Could the different attributes inside the MANIFEST.FM file affect things? Could the presence of the "maven" directory and the copy of the pom file in the jar upset JBoss in any way? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trusting in our own dog food
I read on svn changelog that SVN v1.4 increased a lot the speed for comparing local copy with repository. Maybe continuum is very slow in SVN update because it is using SVN 1.3 (both client and server needs to be updated) see http://subversion.tigris.org/svn_1.4_releasenotes.html just my 2 cents, Federico brettporter wrote: > > Yes, I have a script to automate installing the latest build (though > would need changes if continuum_ci was turned off). > > 1.1 is running very well thanks to some sleuthing by Wendy and quick > fixes from Emmanuel. > > My biggest concern is the scalability of polling. It currently takes > about 30 minutes to just run through all the required svn up commands > to detect if builds are needed for all the Maven projects. > > - Brett > > On 11/01/2007, at 10:26 AM, Arnaud HERITIER wrote: > >> good luck ;-) >> did you update the 2.1 snapshot ? >> >> Arnaud >> >> On 1/11/07, Brett Porter <[EMAIL PROTECTED]> wrote: >>> >>> Folks, >>> >>> I'd like to turn off continuum_ci.sh and instead only use Continuum >>> itself to do CI for Continuum. Any objections? >>> >>> - Brett >>> >>> > > -- View this message in context: http://www.nabble.com/Trusting-in-our-own-dog-food-tf2955860.html#a8276485 Sent from the Continuum - Dev mailing list archive at Nabble.com.
Re: calling vote for 2.0.5
Hello, WAGONHTTP-6 and MNG-2066 are already resolved; the fixes only need to be incorporated in the 2.0.5 (or 2.0.6) release. MNG-2305 should then also be resolved. Greetings Franz Tom Huybrechts schrieb: Can't you "solve" this with -Dhttps.proxyHost=xxx -Dhttps.proxyPort=... ? On 1/11/07, Franz Fehringer <[EMAIL PROTECTED]> wrote: Will this release contain solutions to MNG-2305 MNG-2066 WAGONHTTP-6 ? These issues mean, that it is impossible to access HTTPS (SSL) repositories from behind proxies/firewalls (i.e. from corporate networks). Thanks and greetings Franz Jason van Zyl schrieb: > Hi, > > I want to call a vote for 2.0.5. All the issues that are going to get > done are done. We'll release and move on. > > I would like to start building all releases from a standard machine > with the same JDK. I would like to propose the maven.org machine which > is monitored 24/7 running Linux. It serves as the central repository > but can easily handle a few builds. They can be built from that > machine and deployed to Apache. I think this is far better then each > of us building stuff from our own machines and deploying. > > Otherwise everything for 2.0.5 is ready to go. > > I will also chop up what's in JIRA into some smaller versions as I > think some micro releases for improvements and smaller changes is > better then waiting 7 months for another release. If we schedule them > out them people can decide whether they want to upgrade or not. But I > know there are several things I would like to get in and I know that > Mike/Ralph would like to get in MNG-1577 which we can squeeze into a > 2.0.6 in a week or two. These are micro release. > > Jason. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
In M2_OPTS (or where else?)? Franz Tom Huybrechts schrieb: Can't you "solve" this with -Dhttps.proxyHost=xxx -Dhttps.proxyPort=... ? On 1/11/07, Franz Fehringer <[EMAIL PROTECTED]> wrote: Will this release contain solutions to MNG-2305 MNG-2066 WAGONHTTP-6 ? These issues mean, that it is impossible to access HTTPS (SSL) repositories from behind proxies/firewalls (i.e. from corporate networks). Thanks and greetings Franz Jason van Zyl schrieb: > Hi, > > I want to call a vote for 2.0.5. All the issues that are going to get > done are done. We'll release and move on. > > I would like to start building all releases from a standard machine > with the same JDK. I would like to propose the maven.org machine which > is monitored 24/7 running Linux. It serves as the central repository > but can easily handle a few builds. They can be built from that > machine and deployed to Apache. I think this is far better then each > of us building stuff from our own machines and deploying. > > Otherwise everything for 2.0.5 is ready to go. > > I will also chop up what's in JIRA into some smaller versions as I > think some micro releases for improvements and smaller changes is > better then waiting 7 months for another release. If we schedule them > out them people can decide whether they want to upgrade or not. But I > know there are several things I would like to get in and I know that > Mike/Ralph would like to get in MNG-1577 which we can squeeze into a > 2.0.6 in a week or two. These are micro release. > > Jason. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
Can't you "solve" this with -Dhttps.proxyHost=xxx -Dhttps.proxyPort=... ? On 1/11/07, Franz Fehringer <[EMAIL PROTECTED]> wrote: Will this release contain solutions to MNG-2305 MNG-2066 WAGONHTTP-6 ? These issues mean, that it is impossible to access HTTPS (SSL) repositories from behind proxies/firewalls (i.e. from corporate networks). Thanks and greetings Franz Jason van Zyl schrieb: > Hi, > > I want to call a vote for 2.0.5. All the issues that are going to get > done are done. We'll release and move on. > > I would like to start building all releases from a standard machine > with the same JDK. I would like to propose the maven.org machine which > is monitored 24/7 running Linux. It serves as the central repository > but can easily handle a few builds. They can be built from that > machine and deployed to Apache. I think this is far better then each > of us building stuff from our own machines and deploying. > > Otherwise everything for 2.0.5 is ready to go. > > I will also chop up what's in JIRA into some smaller versions as I > think some micro releases for improvements and smaller changes is > better then waiting 7 months for another release. If we schedule them > out them people can decide whether they want to upgrade or not. But I > know there are several things I would like to get in and I know that > Mike/Ralph would like to get in MNG-1577 which we can squeeze into a > 2.0.6 in a week or two. These are micro release. > > Jason. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
Agree to the plan. Emmanuel Jason van Zyl a écrit : Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving site plugin webapp to another plugin
+1 Emmanuel Jason van Zyl a écrit : Can we put the webapp stuff that's currently in the site plugin in another plugin so that when you simply want to generate your site you don't drag down Jetty and all its dependencies? It really is something unexpected and isn't something most would associate with just generating a site. The functionality is cool, I just think it belong in another plugin. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving site plugin webapp to another plugin
On 1/11/07, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: Jason van Zyl wrote: > Can we put the webapp stuff that's currently in the site plugin in > another plugin so that when you simply want to generate your site you > don't drag down Jetty and all its dependencies? It really is something > unexpected and isn't something most would associate with just generating > a site. The functionality is cool, I just think it belong in another > plugin. +1, it is as you say a bit of a surprise to downlown the J2EE stack to run javadoc or transform some APT :) Same here. +1 -- Trygve - 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 site plugin webapp to another plugin
Jason van Zyl wrote: Can we put the webapp stuff that's currently in the site plugin in another plugin so that when you simply want to generate your site you don't drag down Jetty and all its dependencies? It really is something unexpected and isn't something most would associate with just generating a site. The functionality is cool, I just think it belong in another plugin. +1, it is as you say a bit of a surprise to downlown the J2EE stack to run javadoc or transform some APT :) -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-ear-plugin 2.3.1
+1 fabrizio On 1/8/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote: Hi, I'd like to release the ear plugin which contains a backward compatibility issue in 2.3 [1]. The issue has been fixed and the reporter has validated his builds successfully. Revision 492264 Snapshot available http://people.apache.org/~snicoll/maven-stage-repo/org/apache/maven/plugins/maven-ear-plugin/2.3.1-SNAPSHOT/ Votes open for 72h. My +1, Stéphane [1] http://jira.codehaus.org/browse/MEAR-53 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
Jason van Zyl wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. Then I think it should be released. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. I don't think micro releases is the way to go in general, if you define micro releases to be in the scale of a a couple of weeks. The 7 months that has passes since 2.0.4 is too long, don't get me wrong but having very frequent micro releases is just going to confuse people and lead to inconsistent developer environments. Just a though on making bi-weekly/monthly micro releases the new way. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trusting in our own dog food
Brett Porter wrote: Folks, I'd like to turn off continuum_ci.sh and instead only use Continuum itself to do CI for Continuum. Any objections? I don't see why it should be turned off, but perhaps the automatic notifications can be turned off or just send failures. That way it would verify the product (it will in itself be an integration test) because if the Continuum instance says that something is failing, you should expect an email saying the same right after. Or at least you can check the logs directory if you're suspecting some other failure. -- Trygve
Re: [vote] Collapse Maven permission groups
[x] +1 for the full proposal - collapse all groups (implies a vote for the next option if vote doesn't pass) -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
Will this release contain solutions to MNG-2305 MNG-2066 WAGONHTTP-6 ? These issues mean, that it is impossible to access HTTPS (SSL) repositories from behind proxies/firewalls (i.e. from corporate networks). Thanks and greetings Franz Jason van Zyl schrieb: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: calling vote for 2.0.5
Ralph Goers wrote on Thursday, January 11, 2007 6:38 AM: > Well, if you absolutely positively promise to release 2.0.6 when > MNG-1577 is applied ;-) . Seriously, it has been rather frustrating > as I can't even use Maven 2 without that fix. Yeah, not another 9 months please, I've reported this initially for M2.0.1 ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-war-plugin v2.0.2 in jira
Hi, It looks that version 2.0.2 of maven-war-plugin is not marked as relesed in jira so changes are not visible in changelog - they are in roadmap. Can somebody take care about this? Thanks, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving site plugin webapp to another plugin
+1 Milos On 1/11/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Can we put the webapp stuff that's currently in the site plugin in another plugin so that when you simply want to generate your site you don't drag down Jetty and all its dependencies? It really is something unexpected and isn't something most would associate with just generating a site. The functionality is cool, I just think it belong in another plugin. 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]
