Re: RPMs for Maven 3?
On 3/20/12 5:23 PM, "Stephen Connolly" wrote: >On 20 March 2012 22:49, Benson Margulies wrote: >> On Tue, Mar 20, 2012 at 4:45 PM, Jason Chaffee >> wrote: >>> Just a suggestion. >>> >>> If you can find some people who are not currently commuters and are >>> interested in do thing just this very thing, could they be a partial >>> committer, only working on the RPM's and not the other parts of maven? >>> >>> In my opinion, this is the spirit of open source software. I know >>> everywhere I have been my IT/OPS wanted RPM's for maven. >>> >>> Jason >> >> It's actually simpler than this. If someone posts a reasonable patch >> -- where reasonable means (in my opinion), "could be part of the >> automated Jenkins builds, doesn't inordinately inconvenience people >> building the core on Windows", then some committer might commit it. >> *I* might commit it. > >I might commit it too, but I ain't going to have time to test it, and >I would only commit it in a separate module in a separate tree so that >it could be released separately, but others may have a different >view... I don't see myself raising veto on RPM builds I agree that they should be separate modules, I would expect some type of integration tests that would be written with the modules. However, that is problematic unless maven has a CI environment that could ramp up VM's quickly for the different distributions and test them. Anyway, I would love to see RPM's, but I am not really interested myself in doing them either. Hopefully, someone else can find a good solution and do this work and we can get it added, but I do see the challenges. > >> >> If one of my fellow PMC members found it bottomlessly horrible, they >> could exercise their post-commit review powers and tell me to yank it >> until we had a formal vote. >> >> Once it was in place, then the next question would be, "Would any >> release manager take responsibility for including the results in a >> vote?" >> >> Now, keep in mind that Apache releases are SOURCE releases. The >> binaries are for convenience only. Still, I agree with Stephen C. that >> it would be bad form to put RPMs on /dist that hadn't been supervised >> by the PMC. >> >> The final question, then, as Stephen has pointed out, would be, "would >> a sufficiency of PMC members vote +1 and not -1 for a release with >> them." So far, no PMC member has expressed any enthusiasm for that >> step. >> > >Actually -1 votes don't count. You cannot veto releases, you only >need 3 x +1... so we could have 3 x +1 and 21 x -1 and the release >manager is still allowed to proceed with the release! [It would be bad >form to proceed from my PoV, but the rules allow it] > >-Stephen > >> >> >>> >>> On 3/20/12 7:47 AM, "Stephen Connolly" >>> >>> wrote: >>> >>>>To get the RPMs released, you are going to have to find 3xPMC members >>>>willing to vote +1 for each time you run the release. >>>> >>>>Your best option is to have the RPMs as a separate module that depends >>>>on org.apache.maven:apache-maven and repackages that producing just an >>>>RPM. >>>> >>>>Do not try to integrate it into the core build of Maven, as you will >>>>have too few PMC members willing to vote on the RPM being in the core >>>>dist. >>>> >>>>Profiles would be evil for this case... separate module outside of the >>>>main build is fine. >>>> >>>>-Stephen >>>> >>>>P.S. in case it was not clear from my previous mail, I will not be >>>>using what little time I have to vote on RPM releases. There are >>>>currently 24 people on the PMC list. If you cannot find at least 3 of >>>>them willing to consider voting +1 on RPM releases, then you are SooL >>>> >>>>On 20 March 2012 14:19, Stanislav Ochotnicky >>>>wrote: >>>>> >>>>> I would *really* like for maven to produce RPMs as alternative dist >>>>> output, but I understand your position. I had a quick look into >>>>> rpm-maven-plugin and I believe a reasonable RPM output could be >>>>>achieved >>>>> by using it in with non-default profile. That should also prevent any >>>>> problems with building for Windows users (or all that don't really >>>>>care >>>>> about rpm output
Re: RPMs for Maven 3?
Just a suggestion. If you can find some people who are not currently commuters and are interested in do thing just this very thing, could they be a partial committer, only working on the RPM's and not the other parts of maven? In my opinion, this is the spirit of open source software. I know everywhere I have been my IT/OPS wanted RPM's for maven. Jason On 3/20/12 7:47 AM, "Stephen Connolly" wrote: >To get the RPMs released, you are going to have to find 3xPMC members >willing to vote +1 for each time you run the release. > >Your best option is to have the RPMs as a separate module that depends >on org.apache.maven:apache-maven and repackages that producing just an >RPM. > >Do not try to integrate it into the core build of Maven, as you will >have too few PMC members willing to vote on the RPM being in the core >dist. > >Profiles would be evil for this case... separate module outside of the >main build is fine. > >-Stephen > >P.S. in case it was not clear from my previous mail, I will not be >using what little time I have to vote on RPM releases. There are >currently 24 people on the PMC list. If you cannot find at least 3 of >them willing to consider voting +1 on RPM releases, then you are SooL > >On 20 March 2012 14:19, Stanislav Ochotnicky >wrote: >> >> I would *really* like for maven to produce RPMs as alternative dist >> output, but I understand your position. I had a quick look into >> rpm-maven-plugin and I believe a reasonable RPM output could be achieved >> by using it in with non-default profile. That should also prevent any >> problems with building for Windows users (or all that don't really care >> about rpm output). Or do you consider even this approach unviable? It's >> OK if you do, just want to know if I should keep looking for some >> compromise or if it's really out of the question. >> >> One way or the other I created a simple spec/srpm based on binary maven >> release: >> >> Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec >> SRPM URL: >>http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm >> BINRPM URL: >>http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm >> >> I should note that I don't really intend to support this solution. But I >> might update this together with maven releases since I assume it should >> be fairly easy. >> >> Another request: would you consider adding bash-completion[1] to maven >>sources >> someplace? We have a slightly modified version in Fedora. >> >> [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion >> >> Quoting Jason van Zyl (2012-03-20 13:33:32) >>>Stanislav, >>> >>>If you're going to attempt something do it as an external action that >>>takes the output of the primary build. Don't make something that >>>augments the standard build process. That's invasive and for people >>>building on Windows if problems arise they can't really fix it. If you >>>make an entirely separate build that can consume the output of the >>>standard build then people who are interested can take a look, those >>>who don't care aren't affected. I don't want any specific modifications >>>made to the existing build process to accommodate RPMs. I think a >>>separate build would be more useful as it will be specific to the task >>>at hand and people can use it as they like to produce RPMs for >>>themselves if they so choose. >>> >>>On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: >>> Quoting Jos Backus (2012-03-19 23:40:43) > Hi Manfred, > > On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser > wrote: >> Jos, >> >> I agree with you in the sense that any open source project that >>cares about >> a wide user base should try to provide packages of its software >>that are >> useful to as many people as possible. > > Thanks. >> >> Therefore e.g. the Jenkins effort to offer all sorts of installs is >>laudible >> imho. > > Yes. It increases adoption by lowering the threshold to >install/manage > the software. > >> However for Maven this is clearly not going to happen from the >>current team. >> There is just too much bad experience with old Maven packages >>supplied by >> various parties. > > That's too bad, really, as it will cause people like me to reinvent > the wheel. But I understand the perspective and it's not my place to > tell people how to spend their time. Well let's see if we can change this. I'll try to prepare patch for maven to generate rpms during build that would both work, and not make FHS proponents get angry (too much). If it gets commited: woot. If not at least I can tell my future kids I tried :-) That said I understand what would additional dist target entail for Maven devs. No hard feelings either way >> At this stage I would suggest to make the package yourself the way >>you want >> and host it on you
RE: Moving to TestNG JUnit4?
FYI, JUnit now supports concurrent running of tests. http://junit.org/node/589 Jason -Original Message- From: Jemos Infra [mailto:jemos.in...@googlemail.com] Sent: Monday, June 07, 2010 11:17 AM To: Maven-Dev Subject: Moving to TestNG JUnit4? Hi all, I haven't received any comments on my suggestion to move to Junit4. I find that still using Junit3 is ugly, it still relies on inheritance rather than composition and it doesn't use the potentials of frameworks such as TestNG (which has the ability of running tests in parallel, plus many other features). I'm available to do some job, but I'd need guidance as for the process, since I'm new to this tool from a development perspective. Regards, M. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: turn off javadoc during release
Thanks. this is what I did. However, this is not ideal. I am running release using the reactor on about 100 projects and I really one want to not to javadoc on the single project where it is failing. Jason On Sep 12, 2009, at 6:04 AM, Benjamin Bentmann wrote: > Tony Chemit wrote: > >> Le Thu, 10 Sep 2009 19:41:00 -0700, >> Jason Chaffee a écrit : >> >>> Is there a way to turn off javadoc execution during >>> release:perform? I >>> using -Dgoals=deploy, but javadoc execution is still happening. >> >> from the version 2.5, you can skip the javadoc plugin via the >> configuratin property named skip > > Alternatively, try setting useReleaseProfile [0] to false and define > your own release profile, without the Javadoc Plugin. > > > Benjamin > > > [0] > http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html#useReleaseProfile > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
turn off javadoc during release
Is there a way to turn off javadoc execution during release:perform? I using -Dgoals=deploy, but javadoc execution is still happening. I need to turn it off because it is causing the release to fail. I don't have time to debug the javadoc failure on an internal dependency that does not need javadocs released. This is extremely frustrating... regards, Jason - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
I understand that you probably don't want to commit to a date or cause undue expectations from anyone on this list, so let me ask it in a slight differently way. Do you think it "might" be possible that we see a beta 3.x in 2009? One reason I ask is because I would like to schedule some time in late 2009 for 3.x investigation , but if you know that it will not be available by the end of 2009 then there is no reason to get into our schedule. kind regards, Jason On Sep 7, 2009, at 1:41 PM, Jason van Zyl wrote: > No. > > On 2009-09-07, at 10:40 PM, Jason Chaffee wrote: > >> Any idea when this might be, approximately? >> >> >> On Sep 7, 2009, at 1:36 AM, Jason van Zyl wrote: >> >>> No it's not available and won't be until I'm finished a fully >>> working >>> beta. >>> >>> On 2009-09-07, at 1:42 AM, Christian Edward Gruber wrote: >>> >>>> Is that prototype available? I'd love to see it. >>>> >>>> Christian >>>> >>>> On 2009-09-06, at 18:53 , Jason Chaffee wrote: >>>> >>>>> Cool. Good to hear. >>>>> >>>>> >>>>> On Sep 5, 2009, at 1:42 PM, Jason van Zyl wrote: >>>>> >>>>>> >>>>>> On 2009-09-05, at 10:23 PM, Jason Chaffee wrote: >>>>>> >>>>>>> I agree with you and Jason van Zyl about Maven probably doesn't >>>>>>> need >>>>>>> to support another option. However, it would be nice if the >>>>>>> architecture supported it more easily. >>>>>>> >>>>>> >>>>>> It does and I used it in a prototype Groovy and JRuby sort of >>>>>> version >>>>>> of Maven >>>>>> >>>>>>> This would mean everything is accessed through a clean API and >>>>>>> that >>>>>>> we could easily inject our own POM parser. If someone wrote a >>>>>>> plugin that didn't use the API's correct and bound to the XML, >>>>>>> then >>>>>>> the person that injected his own POM parser and POM format would >>>>>>> be >>>>>>> left to deal with that too. He/She would have to decide if it >>>>>>> is >>>>>>> worth it for them. I imagine some people would still do it and >>>>>>> either sacrifice the use of those plugins or they help to >>>>>>> contribute >>>>>>> to fix them to work the API more appropriately, thus giving back >>>>>>> to >>>>>>> the community in a constructive manner. >>>>>>> >>>>>>> The current problem is that some of the maven code is very nasty >>>>>>> and >>>>>>> some it isn't always easy to inject your own implementations >>>>>>> into >>>>>>> it. >>>>>>> >>>>>>> The way I see it, it is more about building a nice injectable >>>>>>> architecture with really good clean API's, then power users can >>>>>>> basically do whatever they want easily. Therefore, you >>>>>>> wouldn't >>>>>>> be >>>>>>> directly supporting this feature...but by creating a clean >>>>>>> injectable architecture you would support without that intent >>>>>>> anyway. >>>>>>> >>>>>>> This way, the maven team isn't supporting it per se, but rather >>>>>>> the >>>>>>> architecture supports the ability for someone to do it at their >>>>>>> own >>>>>>> risk. >>>>>>> >>>>>>> >>>>>>> kind regards, >>>>>>> >>>>>>> Jason >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Stephen Connolly [stephen.alan.conno...@gmail.com] >>>>>>> Sent: Saturday, September 05, 2009 5:45 AM >>>>>>> To: Maven Developers List >>>>>>> Cc: Maven Developers List >>>>>>> Subject: Re: Re : Re : non-xml poms in 3.x >>>>>>> >>>>>>> personally, given the fun with rewriting X
Re: Re : Re : non-xml poms in 3.x
Any idea when this might be, approximately? On Sep 7, 2009, at 1:36 AM, Jason van Zyl wrote: > No it's not available and won't be until I'm finished a fully working > beta. > > On 2009-09-07, at 1:42 AM, Christian Edward Gruber wrote: > >> Is that prototype available? I'd love to see it. >> >> Christian >> >> On 2009-09-06, at 18:53 , Jason Chaffee wrote: >> >>> Cool. Good to hear. >>> >>> >>> On Sep 5, 2009, at 1:42 PM, Jason van Zyl wrote: >>> >>>> >>>> On 2009-09-05, at 10:23 PM, Jason Chaffee wrote: >>>> >>>>> I agree with you and Jason van Zyl about Maven probably doesn't >>>>> need >>>>> to support another option. However, it would be nice if the >>>>> architecture supported it more easily. >>>>> >>>> >>>> It does and I used it in a prototype Groovy and JRuby sort of >>>> version >>>> of Maven >>>> >>>>> This would mean everything is accessed through a clean API and >>>>> that >>>>> we could easily inject our own POM parser. If someone wrote a >>>>> plugin that didn't use the API's correct and bound to the XML, >>>>> then >>>>> the person that injected his own POM parser and POM format would >>>>> be >>>>> left to deal with that too. He/She would have to decide if it is >>>>> worth it for them. I imagine some people would still do it and >>>>> either sacrifice the use of those plugins or they help to >>>>> contribute >>>>> to fix them to work the API more appropriately, thus giving back >>>>> to >>>>> the community in a constructive manner. >>>>> >>>>> The current problem is that some of the maven code is very nasty >>>>> and >>>>> some it isn't always easy to inject your own implementations into >>>>> it. >>>>> >>>>> The way I see it, it is more about building a nice injectable >>>>> architecture with really good clean API's, then power users can >>>>> basically do whatever they want easily. Therefore, you wouldn't >>>>> be >>>>> directly supporting this feature...but by creating a clean >>>>> injectable architecture you would support without that intent >>>>> anyway. >>>>> >>>>> This way, the maven team isn't supporting it per se, but rather >>>>> the >>>>> architecture supports the ability for someone to do it at their >>>>> own >>>>> risk. >>>>> >>>>> >>>>> kind regards, >>>>> >>>>> Jason >>>>> >>>>> >>>>> >>>>> From: Stephen Connolly [stephen.alan.conno...@gmail.com] >>>>> Sent: Saturday, September 05, 2009 5:45 AM >>>>> To: Maven Developers List >>>>> Cc: Maven Developers List >>>>> Subject: Re: Re : Re : non-xml poms in 3.x >>>>> >>>>> personally, given the fun with rewriting XML at the moment, (see >>>>> versions maven plugin) I would prefer to just have the current XML >>>>> format. adding more formats makes some of the things that the >>>>> versions >>>>> maven current does a little harder to support. >>>>> >>>>> Sent from my [rhymes with myPod] ;-) >>>>> >>>>> On 5 Sep 2009, at 12:00, Julien HENRY wrote: >>>>> >>>>>> In the very specific case of groupId/artifactId/version pattern >>>>>> which is currently very verbose I would tend to agree to allow >>>>>> shorter syntax using attributes instead of elements. >>>>>> >>>>>> >>>>> scope=""/> >>>>>> >>>>>> >>>>>> >>>>>> ... >>>>>> >>>>>> >>>>>> >>>>>> This is not what I consider a "big" change for endusers. >>>>>> >>>>>> Still my 2 cents. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Julien >>>>>> >>>>>> >>>>>> &
Re: Re : Re : non-xml poms in 3.x
Cool. Good to hear. On Sep 5, 2009, at 1:42 PM, Jason van Zyl wrote: > > On 2009-09-05, at 10:23 PM, Jason Chaffee wrote: > >> I agree with you and Jason van Zyl about Maven probably doesn't need >> to support another option. However, it would be nice if the >> architecture supported it more easily. >> > > It does and I used it in a prototype Groovy and JRuby sort of version > of Maven > >> This would mean everything is accessed through a clean API and that >> we could easily inject our own POM parser. If someone wrote a >> plugin that didn't use the API's correct and bound to the XML, then >> the person that injected his own POM parser and POM format would be >> left to deal with that too. He/She would have to decide if it is >> worth it for them. I imagine some people would still do it and >> either sacrifice the use of those plugins or they help to contribute >> to fix them to work the API more appropriately, thus giving back to >> the community in a constructive manner. >> >> The current problem is that some of the maven code is very nasty and >> some it isn't always easy to inject your own implementations into it. >> >> The way I see it, it is more about building a nice injectable >> architecture with really good clean API's, then power users can >> basically do whatever they want easily. Therefore, you wouldn't be >> directly supporting this feature...but by creating a clean >> injectable architecture you would support without that intent anyway. >> >> This way, the maven team isn't supporting it per se, but rather the >> architecture supports the ability for someone to do it at their own >> risk. >> >> >> kind regards, >> >> Jason >> >> >> >> From: Stephen Connolly [stephen.alan.conno...@gmail.com] >> Sent: Saturday, September 05, 2009 5:45 AM >> To: Maven Developers List >> Cc: Maven Developers List >> Subject: Re: Re : Re : non-xml poms in 3.x >> >> personally, given the fun with rewriting XML at the moment, (see >> versions maven plugin) I would prefer to just have the current XML >> format. adding more formats makes some of the things that the >> versions >> maven current does a little harder to support. >> >> Sent from my [rhymes with myPod] ;-) >> >> On 5 Sep 2009, at 12:00, Julien HENRY wrote: >> >>> In the very specific case of groupId/artifactId/version pattern >>> which is currently very verbose I would tend to agree to allow >>> shorter syntax using attributes instead of elements. >>> >>> >> scope=""/> >>> >>> >>> >>> ... >>> >>> >>> >>> This is not what I consider a "big" change for endusers. >>> >>> Still my 2 cents. >>> >>> Regards, >>> >>> Julien >>> >>> >>> >>> - Message d'origine >>>> De : Jason Chaffee >>>> À : Maven Developers List >>>> Envoyé le : Samedi, 5 Septembre 2009, 1h00mn 02s >>>> Objet : RE: Re : non-xml poms in 3.x >>>> >>>> FYI, I know that in the past Resin supported both Elements and >>>> attributes in >>>> it's config XML. It was really neat. If you preferred one over >>>> the other, you >>>> could use it. Don't know if it is still that way though. >>>> >>>> Jason >>>> >>>> From: Jason Chaffee [jason.chaf...@zilliontv.tv] >>>> Sent: Friday, September 04, 2009 3:27 PM >>>> To: Maven Developers List >>>> Subject: RE: Re : non-xml poms in 3.x >>>> >>>> I like the idea of having some things as attributes. >>>> >>>> See the following links on information on when to use attributes >>>> and when to use >>>> elements. >>>> >>>> http://www.ibm.com/developerworks/xml/library/x-eleatt.html >>>> http://nedbatchelder.com/blog/200412/elements_vs_attributes.html >>>> http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Design.pdf >>>> >>>> In particular, from the X12 Reference Model for XML Design: >>>> >>>> 7.2.5 Elements vs. Attributes >>>> Description: Often it is possible to model a data item as a child >>>> element or an >>>> attribute. >>>&g
RE: Re : Re : non-xml poms in 3.x
I agree with you and Jason van Zyl about Maven probably doesn't need to support another option. However, it would be nice if the architecture supported it more easily. This would mean everything is accessed through a clean API and that we could easily inject our own POM parser. If someone wrote a plugin that didn't use the API's correct and bound to the XML, then the person that injected his own POM parser and POM format would be left to deal with that too. He/She would have to decide if it is worth it for them. I imagine some people would still do it and either sacrifice the use of those plugins or they help to contribute to fix them to work the API more appropriately, thus giving back to the community in a constructive manner. The current problem is that some of the maven code is very nasty and some it isn't always easy to inject your own implementations into it. The way I see it, it is more about building a nice injectable architecture with really good clean API's, then power users can basically do whatever they want easily. Therefore, you wouldn't be directly supporting this feature...but by creating a clean injectable architecture you would support without that intent anyway. This way, the maven team isn't supporting it per se, but rather the architecture supports the ability for someone to do it at their own risk. kind regards, Jason From: Stephen Connolly [stephen.alan.conno...@gmail.com] Sent: Saturday, September 05, 2009 5:45 AM To: Maven Developers List Cc: Maven Developers List Subject: Re: Re : Re : non-xml poms in 3.x personally, given the fun with rewriting XML at the moment, (see versions maven plugin) I would prefer to just have the current XML format. adding more formats makes some of the things that the versions maven current does a little harder to support. Sent from my [rhymes with myPod] ;-) On 5 Sep 2009, at 12:00, Julien HENRY wrote: > In the very specific case of groupId/artifactId/version pattern > which is currently very verbose I would tend to agree to allow > shorter syntax using attributes instead of elements. > > scope=""/> > > > > ... > > > > This is not what I consider a "big" change for endusers. > > Still my 2 cents. > > Regards, > > Julien > > > > - Message d'origine >> De : Jason Chaffee >> À : Maven Developers List >> Envoyé le : Samedi, 5 Septembre 2009, 1h00mn 02s >> Objet : RE: Re : non-xml poms in 3.x >> >> FYI, I know that in the past Resin supported both Elements and >> attributes in >> it's config XML. It was really neat. If you preferred one over >> the other, you >> could use it. Don't know if it is still that way though. >> >> Jason >> >> From: Jason Chaffee [jason.chaf...@zilliontv.tv] >> Sent: Friday, September 04, 2009 3:27 PM >> To: Maven Developers List >> Subject: RE: Re : non-xml poms in 3.x >> >> I like the idea of having some things as attributes. >> >> See the following links on information on when to use attributes >> and when to use >> elements. >> >> http://www.ibm.com/developerworks/xml/library/x-eleatt.html >> http://nedbatchelder.com/blog/200412/elements_vs_attributes.html >> http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Design.pdf >> >> In particular, from the X12 Reference Model for XML Design: >> >> 7.2.5 Elements vs. Attributes >> Description: Often it is possible to model a data item as a child >> element or an >> attribute. >> >> Benefits of Using Elements >> >> -They are more extensible because attributes can later be added to >> them without >> affecting a processing application. >> -They can contain other elements. For example, if you want to >> express a textual >> description using XHTML tags, this is not possible if description >> is an >> attribute. >> -They can be repeated. An element may only appear once now, but >> later you may >> wish to extend it to appear multiple times. >> -You have more control over the rules of their appearance. For >> example, you can >> say that a product can either have a number or a productCode child. >> This is not >> possible for attributes. >> -Their order is significant if specified as part of a sequence, >> while the order >> of attributes is not. Obviously, this is only an advantage if you >> care about the >> order. >> -When the values are lengthy, elements tend to be more readable >> than attributes. >> >> >> Disad
RE: Re : non-xml poms in 3.x
FYI, I know that in the past Resin supported both Elements and attributes in it's config XML. It was really neat. If you preferred one over the other, you could use it. Don't know if it is still that way though. Jason ____ From: Jason Chaffee [jason.chaf...@zilliontv.tv] Sent: Friday, September 04, 2009 3:27 PM To: Maven Developers List Subject: RE: Re : non-xml poms in 3.x I like the idea of having some things as attributes. See the following links on information on when to use attributes and when to use elements. http://www.ibm.com/developerworks/xml/library/x-eleatt.html http://nedbatchelder.com/blog/200412/elements_vs_attributes.html http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Design.pdf In particular, from the X12 Reference Model for XML Design: 7.2.5 Elements vs. Attributes Description: Often it is possible to model a data item as a child element or an attribute. Benefits of Using Elements -They are more extensible because attributes can later be added to them without affecting a processing application. -They can contain other elements. For example, if you want to express a textual description using XHTML tags, this is not possible if description is an attribute. -They can be repeated. An element may only appear once now, but later you may wish to extend it to appear multiple times. -You have more control over the rules of their appearance. For example, you can say that a product can either have a number or a productCode child. This is not possible for attributes. -Their order is significant if specified as part of a sequence, while the order of attributes is not. Obviously, this is only an advantage if you care about the order. -When the values are lengthy, elements tend to be more readable than attributes. Disadvantages of Using Elements -Elements require start and end tags, so are therefore more verbose. (NOTE: not all elements require a start and end tag — elements can be declared in a single line.) Benefits of Using Attributes -They are less verbose. -Attributes can be added to the instance by specifying default values. Elements cannot (they must appear to receive a default value). -Attributes are atomic and cannot be extended and its existence should serve to remove any and all possible ambiguity of the element it describes. They are “adjectives” to the element “noun”. Disadvantages of Using Attributes -Attributes may not be extended by adding children, whereas a complex element may be extended by adding additional child elements or attributes. -If attributes are to be used in addition to elements for conveying business data, rules are required for specifying when a specific data item shall be an element or an attribute. Jason From: paulus.benedic...@gmail.com [paulus.benedic...@gmail.com] On Behalf Of Paul Benedict [pbened...@apache.org] Sent: Friday, September 04, 2009 3:05 PM To: Maven Developers List Subject: Re: Re : non-xml poms in 3.x Yes, the XML is verbose, and tooling helps but I think most people write it by hand. The only evolutionary change I support is the ability to specify simple nested elements as attributes. Paul On Fri, Sep 4, 2009 at 4:40 PM, Jason Chaffee wrote: > For what it is worth, I have heard many complaints either about using XML > and/or about the current structure of the XML as well. I have heard this > from developers I have worked with and I have read some blogs about this > too. I can't tell you where those blogs are now because I pretty much > dismissed them as I like using XML myself. > > Jason > > From: Christian Edward Gruber [christianedwardgru...@gmail.com] > Sent: Friday, September 04, 2009 2:29 PM > To: Maven Developers List > Subject: Re: Re : non-xml poms in 3.x > > Who said anything about a reasonable person? :) I don't have such a > hatred - I'm quite used to it, but it has come up in nearly every > client in the last 3 years - not as a final or deal-breaking barrier > to adoption, but a barrier nonetheless. > > I'm happy to support it - I just need a seam or hook where I can > provide something that pre-processes before the maven run to generate > the pom.xml. Maven itself doesn't need to support the alternate > format at all. If it could be something that was auto-detected as > well (or at worst, put into a settings.xml) then that'd be great. > Essentially I'm doing that now with the maven-yamlpom-plugin... it's > just that I have to do a separate run because it modifies the pom.xml, > and so maven fails on the first sync because the pom was modified. > > In a pinch, this can all be handled with shell scripts wrapping maven, > but I'd prefer to have a cleaner place to integrate. > > Christian. > > On Sep 4, 2009,
RE: Re : non-xml poms in 3.x
I like the idea of having some things as attributes. See the following links on information on when to use attributes and when to use elements. http://www.ibm.com/developerworks/xml/library/x-eleatt.html http://nedbatchelder.com/blog/200412/elements_vs_attributes.html http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Design.pdf In particular, from the X12 Reference Model for XML Design: 7.2.5 Elements vs. Attributes Description: Often it is possible to model a data item as a child element or an attribute. Benefits of Using Elements -They are more extensible because attributes can later be added to them without affecting a processing application. -They can contain other elements. For example, if you want to express a textual description using XHTML tags, this is not possible if description is an attribute. -They can be repeated. An element may only appear once now, but later you may wish to extend it to appear multiple times. -You have more control over the rules of their appearance. For example, you can say that a product can either have a number or a productCode child. This is not possible for attributes. -Their order is significant if specified as part of a sequence, while the order of attributes is not. Obviously, this is only an advantage if you care about the order. -When the values are lengthy, elements tend to be more readable than attributes. Disadvantages of Using Elements -Elements require start and end tags, so are therefore more verbose. (NOTE: not all elements require a start and end tag — elements can be declared in a single line.) Benefits of Using Attributes -They are less verbose. -Attributes can be added to the instance by specifying default values. Elements cannot (they must appear to receive a default value). -Attributes are atomic and cannot be extended and its existence should serve to remove any and all possible ambiguity of the element it describes. They are “adjectives” to the element “noun”. Disadvantages of Using Attributes -Attributes may not be extended by adding children, whereas a complex element may be extended by adding additional child elements or attributes. -If attributes are to be used in addition to elements for conveying business data, rules are required for specifying when a specific data item shall be an element or an attribute. Jason From: paulus.benedic...@gmail.com [paulus.benedic...@gmail.com] On Behalf Of Paul Benedict [pbened...@apache.org] Sent: Friday, September 04, 2009 3:05 PM To: Maven Developers List Subject: Re: Re : non-xml poms in 3.x Yes, the XML is verbose, and tooling helps but I think most people write it by hand. The only evolutionary change I support is the ability to specify simple nested elements as attributes. Paul On Fri, Sep 4, 2009 at 4:40 PM, Jason Chaffee wrote: > For what it is worth, I have heard many complaints either about using XML > and/or about the current structure of the XML as well. I have heard this > from developers I have worked with and I have read some blogs about this > too. I can't tell you where those blogs are now because I pretty much > dismissed them as I like using XML myself. > > Jason > > From: Christian Edward Gruber [christianedwardgru...@gmail.com] > Sent: Friday, September 04, 2009 2:29 PM > To: Maven Developers List > Subject: Re: Re : non-xml poms in 3.x > > Who said anything about a reasonable person? :) I don't have such a > hatred - I'm quite used to it, but it has come up in nearly every > client in the last 3 years - not as a final or deal-breaking barrier > to adoption, but a barrier nonetheless. > > I'm happy to support it - I just need a seam or hook where I can > provide something that pre-processes before the maven run to generate > the pom.xml. Maven itself doesn't need to support the alternate > format at all. If it could be something that was auto-detected as > well (or at worst, put into a settings.xml) then that'd be great. > Essentially I'm doing that now with the maven-yamlpom-plugin... it's > just that I have to do a separate run because it modifies the pom.xml, > and so maven fails on the first sync because the pom was modified. > > In a pinch, this can all be handled with shell scripts wrapping maven, > but I'd prefer to have a cleaner place to integrate. > > Christian. > > On Sep 4, 2009, at 5:12 PM, Jason van Zyl wrote: > > > > > On 2009-09-04, at 10:59 PM, Christian Edward Gruber wrote: > > > >> So I agree that it is a valid concern, and there needs to be a > >> canonical format (which will probably be XML) which all artifacts > >> are saved as - but in my source tree, it should be entirely > >> possible to have an alternate way to specify, since
RE: Re : non-xml poms in 3.x
For what it is worth, I have heard many complaints either about using XML and/or about the current structure of the XML as well. I have heard this from developers I have worked with and I have read some blogs about this too. I can't tell you where those blogs are now because I pretty much dismissed them as I like using XML myself. Jason From: Christian Edward Gruber [christianedwardgru...@gmail.com] Sent: Friday, September 04, 2009 2:29 PM To: Maven Developers List Subject: Re: Re : non-xml poms in 3.x Who said anything about a reasonable person? :) I don't have such a hatred - I'm quite used to it, but it has come up in nearly every client in the last 3 years - not as a final or deal-breaking barrier to adoption, but a barrier nonetheless. I'm happy to support it - I just need a seam or hook where I can provide something that pre-processes before the maven run to generate the pom.xml. Maven itself doesn't need to support the alternate format at all. If it could be something that was auto-detected as well (or at worst, put into a settings.xml) then that'd be great. Essentially I'm doing that now with the maven-yamlpom-plugin... it's just that I have to do a separate run because it modifies the pom.xml, and so maven fails on the first sync because the pom was modified. In a pinch, this can all be handled with shell scripts wrapping maven, but I'd prefer to have a cleaner place to integrate. Christian. On Sep 4, 2009, at 5:12 PM, Jason van Zyl wrote: > > On 2009-09-04, at 10:59 PM, Christian Edward Gruber wrote: > >> So I agree that it is a valid concern, and there needs to be a >> canonical format (which will probably be XML) which all artifacts >> are saved as - but in my source tree, it should be entirely >> possible to have an alternate way to specify, since often I've >> found that XML-hatred is a barrier to Maven adoption in some firms. >> > > I have not found this to be a concern. There's lots of other things > that are barrier but the XML has honestly never come up in any > conversations I've had. > >> You should always be able to get the pom.xml... help:canonical-pom >> would be a decent way to quickly do it, and artifacts should be >> published that way - but a Project is an object, and alternate >> serializations shouldn't be a problem. > > Therein lies the problem, the only real canonical form is the object > model. With 3 XML formats which one is the canonical format? The > first one? > >> >> I would, also as an evangelist and implementor of build systems in >> companies, encourage that a company standardize on a format, but if >> that company wants to use YAML, or some other terser, more human >> readable format for the pom, then I'm good with that. > > I'm not. Again this falls into my category of "if you want it that > way, you support it." A company can standardize on whatever it > wants, but I'm not going to hide the real cost of that. We may > ultimately decide it's not worth it having another XML format. There > are a lot more things in 3.0 that interest me then another XML format. > >> >> I used to feel more like you, Brian, but for the sheer intensity of >> hatred of XML out there (as a format for human-maintained source). >> > > Again, I've not witnessed any XML hatred or that being a > justification by a reasonable person not to use Maven. > >> The problem you're describing about one project using one and >> another using a different one - that's no different than one >> project deciding to use a different set of integration test plugins >> (invoker vs. shitty) and confusing the noobs. The bottom line is >> that you're not going to be able to constraint people from going >> for the "new thing" and messing up the inexperienced, so providing >> sane defaults with lots of room to customize is the best option, in >> my view. >> >> Christian. >> >> >> On Sep 4, 2009, at 4:25 PM, Brian Fox wrote: >> Just my 2 cents as a Maven evangelist in a big private company. Even if Maven is around for years now, basic endusers just start to get accustomed to pom.xml and Maven philosophy (really! people are far slowest to change than in OpenSource project team). Please, please don't mess everything. Small additions are fine, but I think a new format is a bad idea even if it is optional. One of advantage of Maven is standardization across all our projects. If there are several format allowed, some projects will start using new one when others are still using the former and it will lead to a total mess. >>> That's my main concern as well to be honest. >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apac
RE: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
Yeah, I got that more as I read more of the threads. Nonetheless, I thought it might be valuable to hear from a couple of users that were just talking about being about to use different implementations. Thanks for the info though. Jason -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: Wednesday, August 12, 2009 6:34 PM To: Maven Developers List Subject: Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon On 12-Aug-09, at 5:37 PM, Jason Chaffee wrote: > It was just yesterday that I was just have a conversation with a > former colleague about wagon issues in 2.x and the difficulty in > switching out implementations. He was running into all kinds of > issues trying to do it and was not very happy about it. Also, this > is something I have mentioned on the this list in the past about one > of the things that I find annoying about maven. > > I know for a fact, that some people do care about switching and it > is a bigger populace than is given credit. > The discussion is really about what we want to support well versus pluggability. Pluggability is easier in 3.x and no work is going to be done on the sub-systems in 2.x to make that as flexible and we're moving to Guice anyway so Plexus is dead. So whoever makes implementations of the retriever or publisher you'll be able to switch more easily in 3.x. In the case of the components that actually come out of this project and the use cases we can reasonably support as an OSS project, I want to start severely constraining that because along with the component is maintenance, testing and documentation. I think we can reasonably support one flavor of each major component and do the necessary ancillary work. I think that will be the impetus for other to make good implementations of what they want instead of thinking all of our implementations, many of which just honestly aren't fully baked, are great. > > > Kind regards, > > Jason > > -Original Message- > From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett > Porter > Sent: Wednesday, August 12, 2009 5:28 PM > To: Maven Developers List > Subject: Re: Replacing old Wagons in Maven 3.0 with the Jetty-client > based Wagon > > > On 12/08/2009, at 8:10 PM, Jason van Zyl wrote: > >> >> On 12-Aug-09, at 3:43 PM, Brett Porter wrote: >> >>> >>> On 12/08/2009, at 5:58 PM, Jason van Zyl wrote: >>> >>>> John, >>> >>> Not John, but I like to think I do a good impression :) >>> >>>> >>>> What's the range of features across the two http Wagon's right now? >>> >>> They really don't do anything more than the underlying httpclient / >>> JDK implementations. HTTP Headers, connection timeout, and then any >>> parameters supported by HTTPClient in that version. >>> >>>> >>>> I assume in some cases we need the functionality of one versus the >>>> other so I would just like to improve the Jetty-client based Wagon >>>> and fix up what's required there, >>> >>> I assume you mean the existing mercury-wagon (and its mercury >>> deps), not a new wagon based on the underlying jetty http client? >>> >> >> Same thing. > > I'm talking about whether it will depend on mercury-core (and sat4j, > and commons-cli) or just jetty-client. (Or the other alternative to > pull out the mercury transport bits as a separate release). > > Note that the current mercury-wagon hasn't been updated to the latest > artifacts, I'm not even sure if it builds once updated. > >> >>>> add any functionality and toss the other two. >>> >>> shouldn't maven 3 equally support switching implementations and >>> instead choosing the new one as a default / only built-in / >>> supported impl? >>> >> >> No. I'll take one good with the same features. That's why I'm asking >> what's in both them. Users just want something that works, I doubt >> anyone cares about switching unless they run into the corner cases >> that force them to use one or the other. > > Presumably those users with edge cases exist since John went to all > that effort to make it happen in 2.2. I'm all for using the Jetty one > and I'm sure they'll fix up any edge cases as we go, but given how > well established the lightweight HTTP one is, it might still be worth > having that available to start with. My impression was that switching > would be easier out of the box in M3's classloading so it wouldn't be > a big deal. > &g
RE: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
It was just yesterday that I was just have a conversation with a former colleague about wagon issues in 2.x and the difficulty in switching out implementations. He was running into all kinds of issues trying to do it and was not very happy about it. Also, this is something I have mentioned on the this list in the past about one of the things that I find annoying about maven. I know for a fact, that some people do care about switching and it is a bigger populace than is given credit. Kind regards, Jason -Original Message- From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett Porter Sent: Wednesday, August 12, 2009 5:28 PM To: Maven Developers List Subject: Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon On 12/08/2009, at 8:10 PM, Jason van Zyl wrote: > > On 12-Aug-09, at 3:43 PM, Brett Porter wrote: > >> >> On 12/08/2009, at 5:58 PM, Jason van Zyl wrote: >> >>> John, >> >> Not John, but I like to think I do a good impression :) >> >>> >>> What's the range of features across the two http Wagon's right now? >> >> They really don't do anything more than the underlying httpclient / >> JDK implementations. HTTP Headers, connection timeout, and then any >> parameters supported by HTTPClient in that version. >> >>> >>> I assume in some cases we need the functionality of one versus the >>> other so I would just like to improve the Jetty-client based Wagon >>> and fix up what's required there, >> >> I assume you mean the existing mercury-wagon (and its mercury >> deps), not a new wagon based on the underlying jetty http client? >> > > Same thing. I'm talking about whether it will depend on mercury-core (and sat4j, and commons-cli) or just jetty-client. (Or the other alternative to pull out the mercury transport bits as a separate release). Note that the current mercury-wagon hasn't been updated to the latest artifacts, I'm not even sure if it builds once updated. > >>> add any functionality and toss the other two. >> >> shouldn't maven 3 equally support switching implementations and >> instead choosing the new one as a default / only built-in / >> supported impl? >> > > No. I'll take one good with the same features. That's why I'm asking > what's in both them. Users just want something that works, I doubt > anyone cares about switching unless they run into the corner cases > that force them to use one or the other. Presumably those users with edge cases exist since John went to all that effort to make it happen in 2.2. I'm all for using the Jetty one and I'm sure they'll fix up any edge cases as we go, but given how well established the lightweight HTTP one is, it might still be worth having that available to start with. My impression was that switching would be easier out of the box in M3's classloading so it wouldn't be a big deal. > >>> I would like to have one good implementation and we can take >>> advantage of the parallelization, PGP, and SSL support in the >>> Jetty client. >> >> I'm still not convinced doing the PGP this low down in the stack is >> a good idea, I'd prefer it got fixed up in the core artifact >> handling so it could be configured from the core and used in scp, >> etc. >> >> - Brett >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/SonatypeNexus > http://twitter.com/SonatypeM2E > -- > > believe nothing, no matter where you read it, > or who has said it, > not even if i have said it, > unless it agrees with your own reason > and your own common sense. > > -- Buddha > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [ANN] Maven Project Info Reports Plugin 2.1.2 Released
Thanks Dennis. From: Dennis Lundberg [denn...@apache.org] Sent: Sunday, July 26, 2009 8:52 AM To: Maven Developers List Subject: Re: [ANN] Maven Project Info Reports Plugin 2.1.2 Released See http://jira.codehaus.org/browse/MNG-1931 for some discussions. Jason Chaffee wrote: > This is probably better to be asked on the dev list... > > > > Is there a particular reason why pluginManagement does not work for reporting > plugins? I would like to manage reporting plugins just as much as any other > plugin. > > I am curious if there is a design reason, or if this was a simply an > oversight that could possibly be changed in the future? > > thanks. > > Jason > > > From: David C. Hicks [dhi...@i-hicks.org] > Sent: Saturday, July 25, 2009 12:05 PM > To: Maven Users List > Subject: Re: [ANN] Maven Project Info Reports Plugin 2.1.2 Released > > Dennis Lundberg wrote: >> David C. Hicks wrote: >> >>> Maybe I misunderstand the meaning of some of this message. MPIR-160 is >>> listed in the release notes. Does this mean it should be fixed in this >>> release? >>> I bumped the version of this plugin in my current project. It still >>> seems to be fetching artifacts remotely. >>> >> Yes, it's supposed to be fixed. Are you sure that you are using the new >> version? Remember that pluginManagement doesn't work for reporting >> plugins, so you need to specify the version number in the reporting >> section of your POM. >> > Ah! That's probably it. I was not aware that reporting plugins didn't > obey the plugin management rules. Thanks for the tip! > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [ANN] Maven Project Info Reports Plugin 2.1.2 Released
This is probably better to be asked on the dev list... Is there a particular reason why pluginManagement does not work for reporting plugins? I would like to manage reporting plugins just as much as any other plugin. I am curious if there is a design reason, or if this was a simply an oversight that could possibly be changed in the future? thanks. Jason From: David C. Hicks [dhi...@i-hicks.org] Sent: Saturday, July 25, 2009 12:05 PM To: Maven Users List Subject: Re: [ANN] Maven Project Info Reports Plugin 2.1.2 Released Dennis Lundberg wrote: > David C. Hicks wrote: > >> Maybe I misunderstand the meaning of some of this message. MPIR-160 is >> listed in the release notes. Does this mean it should be fixed in this >> release? >> I bumped the version of this plugin in my current project. It still >> seems to be fetching artifacts remotely. >> > > Yes, it's supposed to be fixed. Are you sure that you are using the new > version? Remember that pluginManagement doesn't work for reporting > plugins, so you need to specify the version number in the reporting > section of your POM. > Ah! That's probably it. I was not aware that reporting plugins didn't obey the plugin management rules. Thanks for the tip! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released.
I really like the idea of breaking up unit, integration, and functional tests. This is how I would prefer to break up my tests. I had to use TestNG groups to do this effectively in the current scheme of things. Thanks for the link! Jason -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, May 26, 2009 2:14 PM To: Maven Users List Cc: Maven Developers List Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. 2009/5/26 Jason Chaffee > Yep, I concur with you a 100%. I think the solutions for this until now > (FailSafe), were highly undesirable and caused many other issues. > > It might be something the Maven folks might want to think about in the > future, adding support for integration testing in an more appropriate way > (adding the maven dev list for this reason). I know that there is already some proposals bobbing around, e.g. http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies > > > Regards, > > Jason > > > > -Original Message- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: Tuesday, May 26, 2009 1:08 PM > To: Maven Users List > Cc: Maven Users List > Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > > and you'd probably want an integration-test scope as well for > dependencies used for integration testing, and you'd need to add an > integrationTestSources element to the build, as well as > integrationTestResources > > that is if you want to do things properly. > > and I am not opposed to such changes. the failsafe plugin provides a > mostly clean solution *now*. I am fed up waiting for try... finally > phases (which are why failing the build in the integration-test phase > is *bad*)... I am fed up having a big mad configuration section with > multiple executions in my maven-surefire-plugin plugin, which scares > project newcomers, just the get integration tests running correctly... > I am fed up with a separate module for integration tests (of only one > module) because you only really see the failures when it comes time to > release... > > with failsafe, it's part of the standard build for that module. > > if the developers want to skip the its > > mvn package > or > mvn verify -DskipITs > > if they just run mvn install or mvn deploy then the integration tests > will have run. > > if they've bugs in unit tests > > mvn test -Dmaven.surefire.debug=... > > if they've bugs in integration tests > > mvn verify -Dmaven.failsafe.debug=... > > and all I'd added is a simple short snippet to the pom... no execution > hacks, no profile hacks > > don't get me wrong, if somebody has a better solution *pretty please > with catnip on top* show it to us *now* ;-) > > -Stephen > > Sent from my [rhymes with myPod] ;-) > > On 26 May 2009, at 20:33, Jason Chaffee > wrote: > > > Yes, it would basically force Maven to adopt it as a standard and it > > would might mean even adding a itest-compile phase, etc. > > > > Not sure if I prefer this idea over the current protocol, but I do > > think the FailSafe plugin is very good and clever approach to > > integration tests with the way things currently work in Maven. > > > > I am just throwing it out there as idea for the sake of discussion. > > > > Jason > > > > -Original Message- > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > > Sent: Tuesday, May 26, 2009 12:27 PM > > To: Maven Users List > > Cc: Maven Users List > > Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > > > > but that looses source folder config in ide setup, and hacks with > > test- > > compile > > > > Sent from my [rhymes with myPod] ;-) > > > > On 26 May 2009, at 20:22, Jason Chaffee > > wrote: > > > >> One way around the excludes hack is to adopt a different directory > >> structure for it tests and unit tests. For example > >> > >> src/test --> unit tests > >> > >> src/itest --> integration tests > >> > >> Jason > >> > >> -Original Message- > >> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > >> Sent: Tuesday, May 26, 2009 12:12 PM > >> To: Maven Users List > >> Cc: Maven Users List > >> Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > >> > >> I am not opposed to doing so. the block for me is my lack of Apache > >> commit access. > >> > >> there are valid arguments for keeping the
RE: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released.
Yep, I concur with you a 100%. I think the solutions for this until now (FailSafe), were highly undesirable and caused many other issues. It might be something the Maven folks might want to think about in the future, adding support for integration testing in an more appropriate way (adding the maven dev list for this reason). Regards, Jason -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, May 26, 2009 1:08 PM To: Maven Users List Cc: Maven Users List Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. and you'd probably want an integration-test scope as well for dependencies used for integration testing, and you'd need to add an integrationTestSources element to the build, as well as integrationTestResources that is if you want to do things properly. and I am not opposed to such changes. the failsafe plugin provides a mostly clean solution *now*. I am fed up waiting for try... finally phases (which are why failing the build in the integration-test phase is *bad*)... I am fed up having a big mad configuration section with multiple executions in my maven-surefire-plugin plugin, which scares project newcomers, just the get integration tests running correctly... I am fed up with a separate module for integration tests (of only one module) because you only really see the failures when it comes time to release... with failsafe, it's part of the standard build for that module. if the developers want to skip the its mvn package or mvn verify -DskipITs if they just run mvn install or mvn deploy then the integration tests will have run. if they've bugs in unit tests mvn test -Dmaven.surefire.debug=... if they've bugs in integration tests mvn verify -Dmaven.failsafe.debug=... and all I'd added is a simple short snippet to the pom... no execution hacks, no profile hacks don't get me wrong, if somebody has a better solution *pretty please with catnip on top* show it to us *now* ;-) -Stephen Sent from my [rhymes with myPod] ;-) On 26 May 2009, at 20:33, Jason Chaffee wrote: > Yes, it would basically force Maven to adopt it as a standard and it > would might mean even adding a itest-compile phase, etc. > > Not sure if I prefer this idea over the current protocol, but I do > think the FailSafe plugin is very good and clever approach to > integration tests with the way things currently work in Maven. > > I am just throwing it out there as idea for the sake of discussion. > > Jason > > -Original Message- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: Tuesday, May 26, 2009 12:27 PM > To: Maven Users List > Cc: Maven Users List > Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > > but that looses source folder config in ide setup, and hacks with > test- > compile > > Sent from my [rhymes with myPod] ;-) > > On 26 May 2009, at 20:22, Jason Chaffee > wrote: > >> One way around the excludes hack is to adopt a different directory >> structure for it tests and unit tests. For example >> >> src/test --> unit tests >> >> src/itest --> integration tests >> >> Jason >> >> -Original Message- >> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] >> Sent: Tuesday, May 26, 2009 12:12 PM >> To: Maven Users List >> Cc: Maven Users List >> Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. >> >> I am not opposed to doing so. the block for me is my lack of Apache >> commit access. >> >> there are valid arguments for keeping these as separate plugins >> though, eg the none hack that people used to >> configure surefire for multiple executions; debugging tests from an >> IDE; skipping one type of tests, etc >> >> but at the end of the day, if we can find a way to combine to one >> plugin, I'm fine with that >> >> Sent from my [rhymes with myPod] ;-) >> >> On 26 May 2009, at 19:58, Paul Benedict wrote: >> >>> Will there be an effort to add the integration testing features to >>> the >>> original? I would like to not have multiple testing plugins. >>> >>> On Tue, May 26, 2009 at 1:54 PM, Stephen Connolly >>> wrote: >>>> use surefire for unit tests >>>> >>>> use failsafe if you need to set up a integration test environment >>>> and tear >>>> it back down again after the integration tests have ran >>>> >>>> -Stephen >>>> >>>> Sent from my [rhymes with myPod] ;-) >>>> >>>> On 26 May 2009, at 19:34, Wim Deblauwe >>>>
RE: Maven 2.1.0 regression issue w/ testResources outputDirectory
I believe this is a parameter for the plugin configuration itself. For example,
...
org.apache.maven.plugins
maven-resources-plugin
...
foo/bar
...
...
...
-Original Message-
From: Steve Ariantaj [mailto:steve_arian...@tvworks.com]
Sent: Wednesday, March 25, 2009 12:28 PM
To: Maven Developers List
Subject: RE: Maven 2.1.0 regression issue w/ testResources outputDirectory
Thanks for your quick reply, Benjamin.
According to the resource plugin v2.3,
http://maven.apache.org/plugins/maven-resources-plugin/testResources-moj
o.html
there is a required outputDirectory parameter:
http://maven.apache.org/plugins/maven-resources-plugin/testResources-moj
o.html#outputDirectory
and it used to work in 2.0.9. For now, I've removed it and it seems to
work without it, it'd be good to reconcile the documentation w/ the
model. I'd be happy to do this (I haven't done it before, so I'll need
instructions).
Steve
-Original Message-
From: Benjamin Bentmann [mailto:benjamin.bentm...@udo.edu]
Sent: Wednesday, March 25, 2009 12:07 PM
To: Maven Developers List
Subject: Re: Maven 2.1.0 regression issue w/ testResources
outputDirectory
Steve Ariantaj wrote:
> I'm getting the following error with maven 2.1.0. Pom chunk pasted
> below.
>
>
>
${project.build.testOutputDirectory}
>
> Did outputDirectory element's name/order got changed in 2.1.0? This
was
> working fine in 2.0.9.
Compare the Maven Model Reference [0]:
There is no element as a child of .
Benjamin
[0] http://maven.apache.org/ref/2.0.8/maven-model/maven.html
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE] Release Maven Scm 1.2 and maven-release-plugin 2.0-beta-9
Good to hear. :) -Original Message- From: oliver.l...@gmail.com [mailto:oliver.l...@gmail.com] On Behalf Of Olivier Lamy Sent: Monday, March 23, 2009 4:39 PM To: Maven Developers List Subject: Re: [VOTE] Release Maven Scm 1.2 and maven-release-plugin 2.0-beta-9 argh :-) Just tested the release plugin (and the changelog) with svn 1.6.0 and this scm release with success (on cygwin/windows). -- Olivier 2009/3/24 Jason Chaffee : > Subversion 1.6.0 was just released at the end of last week. Not sure if it > has been tested against 1.6.0 or not, but I have already ran into issues with > other software and Subversion 1.6.0just for your info. :) > > -Original Message- > From: oliver.l...@gmail.com [mailto:oliver.l...@gmail.com] On Behalf Of > Olivier Lamy > Sent: Monday, March 23, 2009 3:56 PM > To: Maven Developers List; scm-...@maven.apache.org > Subject: [VOTE] Release Maven Scm 1.2 and maven-release-plugin 2.0-beta-9 > > Hi, > I'd like to release maven-scm 1.2 and maven-release-plugin 2.0-beta-9. > This two release are in only one vote because they are very dependant > due to a fix for people using subversion version > 1.5.0. > > Concerning maven-scm : > We solved 36 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14522&styleName=Html&projectId=10527&Create=Create > > Staging repo: > https://repository.apache.org/content/repositories/maven-staging-52b28ae7ef880d/ > > Staging site: > http://maven.apache.org/scm-1.2 (wait sync) > > Concerning maven-release-plugin : > We solved 12 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14682&styleName=Html&projectId=11144&Create=Create > > Staging repo: > https://repository.apache.org/content/repositories/maven-staging-52b241d05aa847/ > > Staging site: > http://maven.apache.org/plugins/maven-release-plugin-2.0-beta-9/ (wait sync) > > Vote open for 72 hours. > > Here my +1. > > Thanks, > -- > Olivier > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE] Release Maven Scm 1.2 and maven-release-plugin 2.0-beta-9
Subversion 1.6.0 was just released at the end of last week. Not sure if it has been tested against 1.6.0 or not, but I have already ran into issues with other software and Subversion 1.6.0just for your info. :) -Original Message- From: oliver.l...@gmail.com [mailto:oliver.l...@gmail.com] On Behalf Of Olivier Lamy Sent: Monday, March 23, 2009 3:56 PM To: Maven Developers List; scm-...@maven.apache.org Subject: [VOTE] Release Maven Scm 1.2 and maven-release-plugin 2.0-beta-9 Hi, I'd like to release maven-scm 1.2 and maven-release-plugin 2.0-beta-9. This two release are in only one vote because they are very dependant due to a fix for people using subversion version > 1.5.0. Concerning maven-scm : We solved 36 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14522&styleName=Html&projectId=10527&Create=Create Staging repo: https://repository.apache.org/content/repositories/maven-staging-52b28ae7ef880d/ Staging site: http://maven.apache.org/scm-1.2 (wait sync) Concerning maven-release-plugin : We solved 12 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14682&styleName=Html&projectId=11144&Create=Create Staging repo: https://repository.apache.org/content/repositories/maven-staging-52b241d05aa847/ Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.0-beta-9/ (wait sync) Vote open for 72 hours. Here my +1. Thanks, -- Olivier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Maven Meetup @ Sonatype on March 19th & 20th
Hi Jason, I saw the "Maven 3.0: The Maven you will love" write-up and it is very good to see that many of the issues we discussed recently are going to be addressed in Maven 3.0. I think you already know where I stand on the Guice vs. plexus thing. I have one question and one suggestion. My question is whether or not java 1.5 and generics will be leveraged in 3.0? IMO, I think a lot of maven code and api's could be more clear with them. While maven internals might use Guice/plexus or whatever DI container you guys choose, I might throw out a suggestion for plugin creation to find a way to allow developers use whatever DI container of their choosing. I suggest this because I think if you give developers this kind of choice and flexibility in using their own DI container, you will see more people willing to development useful maven plugins. I might be wrong about this, but I know a couple of people personally that avoid writing maven-plugins like the plague because they don't like plexus and the current way of doing it and I am not talking about me. :)) I have seen that some people really like to use one and only container. Personally, I like Guice, Spring, and PicoContainer and I am fine with any of them. However, I have seen some developers that refuse to use any other container than the one they use for everyday development. However, I will say that I feel this is a minor issue compared to all of the other things you are already planning on addressing in 3.0. I am anxiously awaiting a 3.0 build that includes mercury. :) Regards, Jason -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: Thursday, March 12, 2009 1:24 AM To: Maven Developers List Subject: Re: Maven Meetup @ Sonatype on March 19th & 20th On 11-Mar-09, at 11:00 PM, Rahul Thakur wrote: > Hi Jason, > > Any chance if these session recordings will be available to the > wider community after EclipseCon, ApacheCon? > They'll all be publicly available. > Thanks, > > Rahul > > > On 12/03/2009 10:34 a.m., Jason van Zyl wrote: >> Hi, >> >> For those interested in knowing what Sonatype is working on in the >> Maven community, we're having a Maven Meetup the week before >> EclipseCon in Mountain View. >> >> It's a full day of presentations on Maven and related technologies >> like m2eclipse, Nexus, Tycho, Hudson, NMaven, NAR, FlexMojos and >> more. That will be followed up by a full day hackathon. >> >> You can see the full description here: >> >> http://www.sonatype.com/people/2009/03/sonatype-maven-meetup-on-march-19th-20th/ >> >> And you can signup to attend here: >> >> https://docs.sonatype.org/display/COMM/Maven+Meetup+on+March+19th+and+20th+at+Sonatype >> >> We are syncing up with the Hippo folks who are putting on the Maven >> Meetup in Amsterdam (unfortunately the conference organizers didn't >> notice that EclipseCon and ApacheCon are in the same week) as none >> of the Sonatype folks can attend ApacheCon. We are planning to >> record all the sessions on the 19th and so they should be available >> for everyone at ApacheCon. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> -- >> >> the course of true love never did run smooth ... >> >> -- Shakespeare >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Jira account
I am not sure if anyone can help me, but I wasn't able to find an admin email on jira. I changed companies and thus my email changed. I thought I had changed it in jira, but I guess I didn't. Then, yesterday I tried to login, but it wasn't working so I reset my password and of course I never got the email. I would like to continue to use the same user name because I had filed and commented on bugs in the past. Can someone help reset it or help me login in so that I can reset it please? login: jasonchaffee old email: jason_chaf...@tvworks.com regards, Jason - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: maven 2.1 or maven 3.0
Actually, I found this page: http://docs.codehaus.org/display/MAVEN/Maven+3.0.x I cannot tell you how happy I am to hear about the rewriting of the artifact handling. It is the main part of maven that I think has major architectural issues. I very glad to see that Maven developers have realized this as well. kudos. Now I am even more excited for this release. Any idea when it might happen? Is there any chance to play around with a beta? regards, Jason From: Jason Chaffee [jason.chaf...@zilliontv.tv] Sent: Wednesday, February 04, 2009 7:25 PM To: Maven Developers List Cc: us...@maven.apache.org Subject: maven 2.1 or maven 3.0 Is there a timeline for a release and there anywhere I can find documentation on the new features/improvements/changes in said release? regards, Jason - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven 2.1 or maven 3.0
Is there a timeline for a release and there anywhere I can find documentation on the new features/improvements/changes in said release? regards, Jason - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Issue with ArtifactHandler in reactor builds
Likewise. These are the type of bugs that really make maven look bad. I have been promoting maven for well over 5 years now and I am currently converting a new company to maven and we encountered this bug. It really has turned everyone off on Maven and it is making it an uphill battle to convince them that maven does have benefits. From: Stuart McCulloch [mccu...@gmail.com] Sent: Tuesday, February 03, 2009 9:09 PM To: Maven Developers List Subject: Re: Issue with ArtifactHandler in reactor builds 2009/2/4 Jason Chaffee > I found a workaround that works, but it really bothers me because there is > an underlying issue here that is unresolved and could cause any number of > plugins to not work properly. > yep, same here - I really hope it gets fixed sooner rather than later... > Here is the workaround: > > Instead of making a primary artifact, I attach the artifact. > >projectHelper.attachArtifact(project, "exe", null, file); >//project.getArtifact().setFile(file); > > > -Original Message- > From: Jason Chaffee [mailto:jason.chaf...@zilliontv.tv] > Sent: Tuesday, February 03, 2009 12:35 PM > To: Maven Developers List > Subject: RE: Issue with ArtifactHandler in reactor builds > > FYI, I looked into the workaround that was suggested...resetting the > extension in the ArtifactHandler. However, I found that the extension is > set correctly in both the reactor build and individual project build. It is > almost as if there is some code that isn't even using extension, but rather > using packaging. > > -Original Message- > From: Stuart McCulloch [mailto:mccu...@gmail.com] > Sent: Monday, February 02, 2009 10:46 PM > To: dev@maven.apache.org > Subject: Re: Issue with ArtifactHandler in reactor builds > > 2009/2/3 Jason Chaffee > > > I am having an issue on 2.0.9. Basicallly, I have a custom plugin that > has > > it's own packaging type and creates a file of it's own extension type. > This > > only happens if I run a reactor build. If run maven in that project, it > > works correctly. For example, > > > > my-bundle > > > > will create artifactId-version.exe > > > > However, with maven-2.0.9 it creates the file correcting in the target > > directory but it installs it and deploys it as > artifactId-version.my-bundle. > > Here is an example output: > > > > [INFO] Installing > > > C:\workspace\server\manager\project\bundle\target\project-1.0.0-SNAPSHOT.exe > > to C:\Documents and > > > Settings\jason.chaffee\.m2\repository\com\foo\project\project\1.0.0-SNAPSHOT\project-1.0.0-SNAPSHOT.my-bundle > > > > I wrote a similar plugin with a previous company and it worked fine. > That > > was on maven-2.0.7 though. > > > > Here is my component.xml snippet? > > > > > > ... > > > > org.apache.maven.artifact.handler.ArtifactHandler > > my-bundle > > > > > > org.apache.maven.artifact.handler.DefaultArtifactHandler > > > >exe > >my-bundle > >my-bundle > >java > >true > > > > > > > > > > > > Does anyone have any ideas what could be happening here or have a good > way > > to debug this? > > > > hmm, sounds like http://jira.codehaus.org/browse/MNG-2426 (see also > MNG-1682) > > as a workaround you could try to reset the handler extension in your code > before > installing the artifact, but this might require messing around with Maven > internals > > -- > Cheers, Stuart > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Cheers, Stuart - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Issue with ArtifactHandler in reactor builds
I found a workaround that works, but it really bothers me because there is an underlying issue here that is unresolved and could cause any number of plugins to not work properly. Here is the workaround: Instead of making a primary artifact, I attach the artifact. projectHelper.attachArtifact(project, "exe", null, file); //project.getArtifact().setFile(file); -Original Message----- From: Jason Chaffee [mailto:jason.chaf...@zilliontv.tv] Sent: Tuesday, February 03, 2009 12:35 PM To: Maven Developers List Subject: RE: Issue with ArtifactHandler in reactor builds FYI, I looked into the workaround that was suggested...resetting the extension in the ArtifactHandler. However, I found that the extension is set correctly in both the reactor build and individual project build. It is almost as if there is some code that isn't even using extension, but rather using packaging. -Original Message- From: Stuart McCulloch [mailto:mccu...@gmail.com] Sent: Monday, February 02, 2009 10:46 PM To: dev@maven.apache.org Subject: Re: Issue with ArtifactHandler in reactor builds 2009/2/3 Jason Chaffee > I am having an issue on 2.0.9. Basicallly, I have a custom plugin that has > it's own packaging type and creates a file of it's own extension type. This > only happens if I run a reactor build. If run maven in that project, it > works correctly. For example, > > my-bundle > > will create artifactId-version.exe > > However, with maven-2.0.9 it creates the file correcting in the target > directory but it installs it and deploys it as artifactId-version.my-bundle. > Here is an example output: > > [INFO] Installing > C:\workspace\server\manager\project\bundle\target\project-1.0.0-SNAPSHOT.exe > to C:\Documents and > Settings\jason.chaffee\.m2\repository\com\foo\project\project\1.0.0-SNAPSHOT\project-1.0.0-SNAPSHOT.my-bundle > > I wrote a similar plugin with a previous company and it worked fine. That > was on maven-2.0.7 though. > > Here is my component.xml snippet? > > > ... > > org.apache.maven.artifact.handler.ArtifactHandler > my-bundle > > > org.apache.maven.artifact.handler.DefaultArtifactHandler > >exe >my-bundle >my-bundle >java >true > > > > > > Does anyone have any ideas what could be happening here or have a good way > to debug this? > hmm, sounds like http://jira.codehaus.org/browse/MNG-2426 (see also MNG-1682) as a workaround you could try to reset the handler extension in your code before installing the artifact, but this might require messing around with Maven internals -- Cheers, Stuart - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Issue with ArtifactHandler in reactor builds
FYI, I looked into the workaround that was suggested...resetting the extension in the ArtifactHandler. However, I found that the extension is set correctly in both the reactor build and individual project build. It is almost as if there is some code that isn't even using extension, but rather using packaging. -Original Message- From: Stuart McCulloch [mailto:mccu...@gmail.com] Sent: Monday, February 02, 2009 10:46 PM To: dev@maven.apache.org Subject: Re: Issue with ArtifactHandler in reactor builds 2009/2/3 Jason Chaffee > I am having an issue on 2.0.9. Basicallly, I have a custom plugin that has > it's own packaging type and creates a file of it's own extension type. This > only happens if I run a reactor build. If run maven in that project, it > works correctly. For example, > > my-bundle > > will create artifactId-version.exe > > However, with maven-2.0.9 it creates the file correcting in the target > directory but it installs it and deploys it as artifactId-version.my-bundle. > Here is an example output: > > [INFO] Installing > C:\workspace\server\manager\project\bundle\target\project-1.0.0-SNAPSHOT.exe > to C:\Documents and > Settings\jason.chaffee\.m2\repository\com\foo\project\project\1.0.0-SNAPSHOT\project-1.0.0-SNAPSHOT.my-bundle > > I wrote a similar plugin with a previous company and it worked fine. That > was on maven-2.0.7 though. > > Here is my component.xml snippet? > > > ... > > org.apache.maven.artifact.handler.ArtifactHandler > my-bundle > > > org.apache.maven.artifact.handler.DefaultArtifactHandler > >exe >my-bundle >my-bundle >java >true > > > > > > Does anyone have any ideas what could be happening here or have a good way > to debug this? > hmm, sounds like http://jira.codehaus.org/browse/MNG-2426 (see also MNG-1682) as a workaround you could try to reset the handler extension in your code before installing the artifact, but this might require messing around with Maven internals -- Cheers, Stuart - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Issue with ArtifactHandler in reactor builds
Yep, that is it. I have the same problem with a servicemix plugin as well. It must be a bug with some dependency that is used by maven because not everyone is experiencing this behavior. I have a colleague at a former company that has tried both plugins in his environment with maven-2.0.9 and it works properly for him. These are rather nasty bugs to deal with in maven because they are so difficult to pinpoint what is going on. Also, bugs that happen with the reactor, but do not happen when the individual project is built are quite common in maven, from my experience over the last 3 years or so. These bugs eat up many man hours trying to debug. We have found that the only way we can be sure that something works in maven is to test not only on an individual project, but a project with at least 3 levels of inheritance. Also, we need to blow away the local repo and try downloading fresh artifacts to see if downloading new artifacts causes strange behavior. We have found that if we don't test all 3 scenarios, we can end up with major maven issues that can cost developers many lost days. Sadly, it makes many people dislike maven and want to go back to ant. We have taken many precautions, such as locking down plugin versions and using depedencyManagement to control versions of jars, but we still encounter these issues. Sometimes, I wonder if it is worth it as I spend more time solving maven issues that developing code for my company...sigh Jason -Original Message- From: Stuart McCulloch [mailto:mccu...@gmail.com] Sent: Monday, February 02, 2009 10:46 PM To: dev@maven.apache.org Subject: Re: Issue with ArtifactHandler in reactor builds 2009/2/3 Jason Chaffee > I am having an issue on 2.0.9. Basicallly, I have a custom plugin that has > it's own packaging type and creates a file of it's own extension type. This > only happens if I run a reactor build. If run maven in that project, it > works correctly. For example, > > my-bundle > > will create artifactId-version.exe > > However, with maven-2.0.9 it creates the file correcting in the target > directory but it installs it and deploys it as artifactId-version.my-bundle. > Here is an example output: > > [INFO] Installing > C:\workspace\server\manager\project\bundle\target\project-1.0.0-SNAPSHOT.exe > to C:\Documents and > Settings\jason.chaffee\.m2\repository\com\foo\project\project\1.0.0-SNAPSHOT\project-1.0.0-SNAPSHOT.my-bundle > > I wrote a similar plugin with a previous company and it worked fine. That > was on maven-2.0.7 though. > > Here is my component.xml snippet? > > > ... > > org.apache.maven.artifact.handler.ArtifactHandler > my-bundle > > > org.apache.maven.artifact.handler.DefaultArtifactHandler > >exe >my-bundle >my-bundle >java >true > > > > > > Does anyone have any ideas what could be happening here or have a good way > to debug this? > hmm, sounds like http://jira.codehaus.org/browse/MNG-2426 (see also MNG-1682) as a workaround you could try to reset the handler extension in your code before installing the artifact, but this might require messing around with Maven internals -- Cheers, Stuart - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Issue with ArtifactHandler in reactor builds
I am having an issue on 2.0.9. Basicallly, I have a custom plugin that has it's own packaging type and creates a file of it's own extension type. This only happens if I run a reactor build. If run maven in that project, it works correctly. For example, my-bundle will create artifactId-version.exe However, with maven-2.0.9 it creates the file correcting in the target directory but it installs it and deploys it as artifactId-version.my-bundle. Here is an example output: [INFO] Installing C:\workspace\server\manager\project\bundle\target\project-1.0.0-SNAPSHOT.exe to C:\Documents and Settings\jason.chaffee\.m2\repository\com\foo\project\project\1.0.0-SNAPSHOT\project-1.0.0-SNAPSHOT.my-bundle I wrote a similar plugin with a previous company and it worked fine. That was on maven-2.0.7 though. Here is my component.xml snippet? ... org.apache.maven.artifact.handler.ArtifactHandler my-bundle org.apache.maven.artifact.handler.DefaultArtifactHandler exe my-bundle my-bundle java true Does anyone have any ideas what could be happening here or have a good way to debug this?
RE: [2.0.9 RC8] Release Candidate testing
This is exactly why we lock down plugins ourself. However, I was just
curious to know how it would impact that and how it would impact the use
of the enforcer plugin to catch plugins not locked down.
Thanks.
-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 3:54 PM
To: Maven Developers List
Subject: Re: [2.0.9 RC8] Release Candidate testing
Hmm, well jason, it really is as simple as the super pom (that pom-4.0.0
thingy) listing out all of the plugins and specifying a specific version
number on them. I'm taking a peek at the RC5 version of the superpom
(havn't
gotten around to 6, 7, or 8 now) and it looks like it is using the most
recent version (at least according to the plugins page) of a lot of
different plugins.
So what it means is that if you specify in your pom a different version,
yours will take precendence over the locked down versions.
The whole purpose of the lockdown is simply so that a project you are
working on today will still work 3 years later and not break because
suddenly a new version of a plugin was made within the next 3 years and
you
forgot to lock it to the older version and so it pulled down the
latest/greated automagically and broke everything that you had in
production
:)
On Thu, Apr 3, 2008 at 4:23 PM, Jason Chaffee
<[EMAIL PROTECTED]>
wrote:
> Brian,
>
> Is there any documentation about the new "locked down" plugin in
feature
> in 2.0.9?
>
> I would like to know how it works, how it impacts not having plugins
> locked vs. having them locked down already in your pom and how it
would
> impact the enforcer plugin as well.
>
> Thanks.
>
> -Original Message-
> From: Brian E. Fox [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 03, 2008 12:52 PM
> To: Maven Users List
> Cc: Maven Developers List
> Subject: [2.0.9 RC8] Release Candidate testing
>
> RC8 posted to solve this regression.
>
http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
>
che-maven/<http://people.apache.org/%7Ebrianf/staging-repository/org/apa
che/maven/apache-maven/>
>
> -Original Message-
> From: Kaizer H. Sogiawala [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 03, 2008 2:51 PM
> To: Maven Users List
> Subject: Re: [2.0.9 RC7] Release Candidate testing
>
> I debugged through the source and can confirm
> "${basedir}" is the issue.
>
> On Thu, Apr 3, 2008 at 8:42 AM, John Casey <[EMAIL PROTECTED]>
> wrote:
> > FWIW, using:
> >
> >
> > ${basedir}
> >
> >
> > will express this error. See
http://jira.codehaus.org/browse/MNG-3498
> >
> > I have the fix, just need to get it cleaned up and committed.
> >
> > -john
> >
> >
> >
> > On Apr 3, 2008, at 11:23 AM, Brett Porter wrote:
> >
> >
> > > -1 could be empty string, and there were some hacks in the project
> > > builder that set expressions to that. I know that the path
> translator
> > > was effected by interpolation changes, even though indirectly,
> because
> > > the values got interpolated after instead of before.
> > >
> > > I'd look at those changes - though a POM that reproduces it is
> > > probably necessary to do so.
> > >
> > > - Brett
> > >
> > > On 04/04/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> > >
> > > > Do you have a way to reproduce this? The DefaultPathTranslator
> class
> > > > hasn't changed since 2.0.6 so it must be a higher level change
> we're
> > > > looking for.
> > > >
> > > >
> > > > -Original Message-
> > > > From: Kaizer H. Sogiawala [mailto:[EMAIL PROTECTED]
> > > > Sent: Thursday, April 03, 2008 12:49 AM
> > > > To: Maven Users List
> > > >
> > > > Subject: Re: [2.0.9 RC7] Release Candidate testing
> > > >
> > > > I am getting a strange behavior with apache-maven-2.0.9-RC*
(all
> RC)
> > > > builds. Here is what I see-
> > > >
> > > > --- SNIP ---
> > > > + Error stacktraces are turned on.
> > > > Maven version: 2.0.9-RC7
> > > > Java version: 1.5.0_12
> > > > OS name: "windows xp" version: "5.1" arch: "x86" Family:
> "windows"
> > > > [DEBUG] Building Maven user-level plugin registry from:
> 'C:\Documents
> > > > and Settings\blip\.m2\plugin-registry.xml'
> > > > [DEBUG] Building Maven global-level plugin registry from:
> 'C:\Program
> > > > Files\maven\bin\..\conf\
RE: [2.0.9 RC8] Release Candidate testing
Brian,
Is there any documentation about the new "locked down" plugin in feature
in 2.0.9?
I would like to know how it works, how it impacts not having plugins
locked vs. having them locked down already in your pom and how it would
impact the enforcer plugin as well.
Thanks.
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 12:52 PM
To: Maven Users List
Cc: Maven Developers List
Subject: [2.0.9 RC8] Release Candidate testing
RC8 posted to solve this regression.
http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
che-maven/
-Original Message-
From: Kaizer H. Sogiawala [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 2:51 PM
To: Maven Users List
Subject: Re: [2.0.9 RC7] Release Candidate testing
I debugged through the source and can confirm
"${basedir}" is the issue.
On Thu, Apr 3, 2008 at 8:42 AM, John Casey <[EMAIL PROTECTED]>
wrote:
> FWIW, using:
>
>
> ${basedir}
>
>
> will express this error. See http://jira.codehaus.org/browse/MNG-3498
>
> I have the fix, just need to get it cleaned up and committed.
>
> -john
>
>
>
> On Apr 3, 2008, at 11:23 AM, Brett Porter wrote:
>
>
> > -1 could be empty string, and there were some hacks in the project
> > builder that set expressions to that. I know that the path
translator
> > was effected by interpolation changes, even though indirectly,
because
> > the values got interpolated after instead of before.
> >
> > I'd look at those changes - though a POM that reproduces it is
> > probably necessary to do so.
> >
> > - Brett
> >
> > On 04/04/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> >
> > > Do you have a way to reproduce this? The DefaultPathTranslator
class
> > > hasn't changed since 2.0.6 so it must be a higher level change
we're
> > > looking for.
> > >
> > >
> > > -Original Message-
> > > From: Kaizer H. Sogiawala [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, April 03, 2008 12:49 AM
> > > To: Maven Users List
> > >
> > > Subject: Re: [2.0.9 RC7] Release Candidate testing
> > >
> > > I am getting a strange behavior with apache-maven-2.0.9-RC* (all
RC)
> > > builds. Here is what I see-
> > >
> > > --- SNIP ---
> > > + Error stacktraces are turned on.
> > > Maven version: 2.0.9-RC7
> > > Java version: 1.5.0_12
> > > OS name: "windows xp" version: "5.1" arch: "x86" Family:
"windows"
> > > [DEBUG] Building Maven user-level plugin registry from:
'C:\Documents
> > > and Settings\blip\.m2\plugin-registry.xml'
> > > [DEBUG] Building Maven global-level plugin registry from:
'C:\Program
> > > Files\maven\bin\..\conf\plugin-registry.xml'
> > > [INFO] Scanning for projects...
> > > :
> > > : *blip blip*
> > > :
> > > [INFO]
> > >
>
> > > [ERROR] FATAL ERROR
> > > [INFO]
> > >
>
> > > [INFO] String index out of range: -1
> > > [INFO]
> > >
>
> > > [DEBUG] Trace
> > > java.lang.StringIndexOutOfBoundsException: String index out of
range:
> -1
> > >at java.lang.String.substring(String.java:1768)
> > >at java.lang.String.substring(String.java:1735)
> > >at
> > >
>
org.apache.maven.project.path.DefaultPathTranslator.stripBasedirToken(De
> > > faultPathTranslator.java:101)
> > >at
> > >
>
org.apache.maven.project.path.DefaultPathTranslator.alignToBaseDirectory
> > > (DefaultPathTranslator.java:82)
> > >at
> > >
>
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(
> > > DefaultMavenProjectBuilder.java:992)
> > >at
> > >
>
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Defaul
> > > tMavenProjectBuilder.java:867)
> > >at
> > >
>
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileI
> > > nternal(DefaultMavenProjectBuilder.java:495)
> > >at
> > >
>
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenPr
> > > ojectBuilder.java:198)
> > >at
> > > org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
> > >at
> > >
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
> > >at
> > > org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
> > >at
> > > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
> > >at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> > >at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> > >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
> > >at
> > >
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> > > a:39)
> > >at
> > >
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> > > Impl.java:25)
> > >at java.lang.reflect.Method.invoke(Method.jav
RE: maven vs openmake mesiter
Also, this may have been written before the dependency plugin had the current feature set. I know when I first started using maven2 and the dependency plugin, it only had copy, unpack, and a couple of other goals. It didn't have everything it has now. -Original Message- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2008 7:56 AM To: Maven Developers List Subject: Re: maven vs openmake mesiter Heh, it looks to me like people who have had bad experiences with maven but not known the tools that can help. The command "mvn dependency:tree" would have saved them a paragraph of rant at least! Andy On 31 Mar 2008, at 22:59, Jason van Zyl wrote: > I have something written but it's not very nice. But we're obviously > a threat as they make comparisons to us. A victim of our own > success. I've also meant to follow up on when they started using the > term "Mojo" which definitely confuses people. For the sister Maven > project over at Codehaus called Mojo has been around quite a long > time. So I just didn't want to be disappointed and I'm hoping that > they didn't do it to confuse users. I am assuming not but I haven't > looked up the dates. > > I will try to remove the barbs from my write-up, as their marketing > I frankly find distasteful. But I'll try to be objective and publish > it. > > On 31-Mar-08, at 2:18 PM, Jason Chaffee wrote: >> I came across OpenMake's meister over the weekend and wondered if >> anyone >> on this list has any experience with or any comparison with Maven? I >> was just curious what the maven community's impression/response >> would be >> because they claim to have maven-like features, but they also claim >> to >> go "above and beyond" maven in flexibility and features. >> >> >> >> http://www.openmakesoftware.com/Maven-VS-Meister/ >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > -- > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > > - > 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]
maven vs openmake mesiter
I came across OpenMake's meister over the weekend and wondered if anyone on this list has any experience with or any comparison with Maven? I was just curious what the maven community's impression/response would be because they claim to have maven-like features, but they also claim to go "above and beyond" maven in flexibility and features. http://www.openmakesoftware.com/Maven-VS-Meister/
RE: surefire and testng integration issues with surefire-2.4.2
Thanks Dana for the nice summary. Dan, one thing I did not take into account is that my company my be using TestNG in a different way, such as group of tests, that allows this to work for me and would cause different output for a "standard" user. Think this was a good summary that helped to point out how you could be seeing one thing and I am seeing something different. I suspect this is what is happening. This would suggest that maybe my custom solution is best for my company, whereas a more generic solution might be necessary for it be applied to the surefire plugin. However, one thing that might be nice is to have those methods implemented and have surefire configuration that allows someone to turn it on/off. So, if they want the verbose output coming from the TestNGReporter ITestListener callbacks, then they can enable/disable them. Just a thought. Also, I would like thank you Dan for the way you responded and communicated through this entire process. You did a good job of communicating the issues and we eventually found where our disconnect was at. This allows everyone to understand the issues better and to solve them appropriately. Regards, Jason -Original Message- From: P'Simer, Dana (Matrix) [mailto:Dana.P'[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 11:03 AM To: Maven Users List; Maven Developers List Cc: [EMAIL PROTECTED] Subject: RE: surefire and testng integration issues with surefire-2.4.2 I think part of the disconnect might be in the understanding of what TestNG calls a "test". A test, in testNG terminology, is a logical grouping of testMethods within a suite. A single "test" will span all of the classes in the src/test/java directory unless something is done to break them up. There is no notification based on class unless the test methods for each class are included in separate tests. The default behavior for TestNG in the surefire plugin is to lump all the test methods from all the test classes into one test. That is why only one onStart is called. I have only been using testNG since v5.6 so I don't know when this changed, if it did. However there are ways around this. We use @Test annotations on our test classes with suiteName and testName set so that the methods in each class are segregated into separate tests. Hope this helps clear up any confusion. Thanks, Dana H. P'Simer Dana.P'[EMAIL PROTECTED] -Original Message- From: Dan Fabulich [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 1:25 PM To: Maven Developers List Cc: [EMAIL PROTECTED]; Maven Users List Subject: Re: surefire and testng integration issues with surefire-2.4.2 Jason Chaffee wrote: > Maybe our disconnect is about callbacks after the class vs. the method. > That could be where the misunderstanding is coming from. Sure, that could be. I claim that logging per-method is *way* too much logging. Don't you agree? In JUnit we can log per-class or per-method, but in TestNG we can only log per-method. I think that means we should complain to the TestNG team! :-) What do you think? -Dan - 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: surefire and testng integration issues with surefire-2.4.2
Thanks Dan, I will take a look at it and make sure we are clear and there aren't any misunderstandings before I make any more comments. :) -Original Message- From: Dan Fabulich [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 10:43 AM To: Maven Developers List Cc: Maven Users List Subject: Re: surefire and testng integration issues with surefire-2.4.2 Dan Fabulich wrote: > Jason Chaffee wrote: > >> I did not run your project. > > Well, try it and get back to me. You can use that as a starting point for > reproducing the effect you actually want. Oops, you can't, because the mailing list software stripped my attachment. You can get a copy here: http://www.theblackforge.net/tmphtml/testngListenerTest.zip -Dan - 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: Re: surefire and testng integration issues with surefire-2.4.2
I did not run your project. I created my own listener and ran it in testng, outside of maven in a test environment at my company. I will have to create a different one before I can share it with a wider audience and I would like to actually test it in maven and with surefire to see if the behavior still works as expected. -Original Message- From: Dan Fabulich [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 10:18 AM To: Maven Developers List Cc: [EMAIL PROTECTED]; Maven Users List Subject: Re: surefire and testng integration issues with surefire-2.4.2 Jason Chaffee wrote: > I did try it. I created my own listener and got the exact output I was > looking for. I am not sure where our disconnect is here, but we > certainly are seeing two different things with respect to the code. Did you run my project? What did you see? I see: Example onStart Example onTestStart Example onTestSuccess Example onTestStart Example onTestSuccess Example onFinish (Actually I just did a clean run and realized I'd forgotten to set 1.5 as the compiler source/target, use this attached one instead.) -Dan > -Original Message- > From: Dan Fabulich [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 20, 2008 10:05 AM > To: Maven Developers List > Cc: Maven Users List; [EMAIL PROTECTED] > Subject: Re: surefire and testng integration issues with surefire-2.4.2 > > Jason Chaffee wrote: > >> I brought this up in the past the maven guys were adamant that they > were >> not able to get per test information to output on the console unless >> testng changed. > > That's not what I said! :-) I said that you can't get CLASS > notifications > unless TestNG changes. You can get notification at the start/end of the > > entire run, and you can get notification at the start/end of every > method, > but you can't get notification at the start/end of every class. > >> TestNG does support this functionality with the ITestListener. >> For example, onStart() will give the start of running a particular > class >> configuration and test methods and onFinish() will be called after all >> of the configuration and test methods have been run. > > Sorry, dude, that's not what onStart does. Did you actually try it? > > I've attached a sample project that simply attaches an ITestListener > that > logs to system.out whenever it gets called, specifically during onStart > and onFinish. It's got two test classes: Foo and Bar, each of which > have > one method "foo()" and "bar()" respectively. So you'd expect: > > onStart [Foo] > onTestStart [foo()] > onTestFinish [foo()] > onFinish [Foo] > onStart [Bar] > onTestStart [bar()] > onTestFinish [bar()] > onFinish [Bar] > > But here's what you get instead: > > onStart > onTestStart [foo()] > onTestFinish [foo()] > onTestStart [bar()] > onTestFinish [bar()] > onFinish > > ... not too useful, is it? In fact, onStart is called at the start/end > of > the "test" which is TestNG's very silly term for a collection of tests > that isn't a "group" or a "suite". > > -Dan > > - > 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: RE: Re: surefire and testng integration issues with surefire-2.4.2
Maybe our disconnect is about callbacks after the class vs. the method. That could be where the misunderstanding is coming from. -Original Message- From: Jason Chaffee [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 10:11 AM To: [EMAIL PROTECTED]; Maven Developers List Cc: Maven Users List Subject: RE: Re: surefire and testng integration issues with surefire-2.4.2 I did try it. I created my own listener and got the exact output I was looking for. I am not sure where our disconnect is here, but we certainly are seeing two different things with respect to the code. -Original Message- From: Dan Fabulich [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 10:05 AM To: Maven Developers List Cc: Maven Users List; [EMAIL PROTECTED] Subject: Re: surefire and testng integration issues with surefire-2.4.2 Jason Chaffee wrote: > I brought this up in the past the maven guys were adamant that they were > not able to get per test information to output on the console unless > testng changed. That's not what I said! :-) I said that you can't get CLASS notifications unless TestNG changes. You can get notification at the start/end of the entire run, and you can get notification at the start/end of every method, but you can't get notification at the start/end of every class. > TestNG does support this functionality with the ITestListener. > For example, onStart() will give the start of running a particular class > configuration and test methods and onFinish() will be called after all > of the configuration and test methods have been run. Sorry, dude, that's not what onStart does. Did you actually try it? I've attached a sample project that simply attaches an ITestListener that logs to system.out whenever it gets called, specifically during onStart and onFinish. It's got two test classes: Foo and Bar, each of which have one method "foo()" and "bar()" respectively. So you'd expect: onStart [Foo] onTestStart [foo()] onTestFinish [foo()] onFinish [Foo] onStart [Bar] onTestStart [bar()] onTestFinish [bar()] onFinish [Bar] But here's what you get instead: onStart onTestStart [foo()] onTestFinish [foo()] onTestStart [bar()] onTestFinish [bar()] onFinish ... not too useful, is it? In fact, onStart is called at the start/end of the "test" which is TestNG's very silly term for a collection of tests that isn't a "group" or a "suite". -Dan - 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: Re: surefire and testng integration issues with surefire-2.4.2
I did try it. I created my own listener and got the exact output I was looking for. I am not sure where our disconnect is here, but we certainly are seeing two different things with respect to the code. -Original Message- From: Dan Fabulich [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 10:05 AM To: Maven Developers List Cc: Maven Users List; [EMAIL PROTECTED] Subject: Re: surefire and testng integration issues with surefire-2.4.2 Jason Chaffee wrote: > I brought this up in the past the maven guys were adamant that they were > not able to get per test information to output on the console unless > testng changed. That's not what I said! :-) I said that you can't get CLASS notifications unless TestNG changes. You can get notification at the start/end of the entire run, and you can get notification at the start/end of every method, but you can't get notification at the start/end of every class. > TestNG does support this functionality with the ITestListener. > For example, onStart() will give the start of running a particular class > configuration and test methods and onFinish() will be called after all > of the configuration and test methods have been run. Sorry, dude, that's not what onStart does. Did you actually try it? I've attached a sample project that simply attaches an ITestListener that logs to system.out whenever it gets called, specifically during onStart and onFinish. It's got two test classes: Foo and Bar, each of which have one method "foo()" and "bar()" respectively. So you'd expect: onStart [Foo] onTestStart [foo()] onTestFinish [foo()] onFinish [Foo] onStart [Bar] onTestStart [bar()] onTestFinish [bar()] onFinish [Bar] But here's what you get instead: onStart onTestStart [foo()] onTestFinish [foo()] onTestStart [bar()] onTestFinish [bar()] onFinish ... not too useful, is it? In fact, onStart is called at the start/end of the "test" which is TestNG's very silly term for a collection of tests that isn't a "group" or a "suite". -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: surefire and testng integration issues with surefire-2.4.2
Yeah, I have no problem writing my own. However, if this is to be expected of TestNG users to get similar output as previous versions of surefire, then it should be WELL documented as such. My issue is that the behavior changed between surefire versions. This caused all kinds of confusion for developers at my company, they needed the latest version of testng to support some functionality, but they had to use the latest surefire to use the latest testng and all of a sudden the output completely disappeared. The frustrating part is the maven developers who worked on surefire claimed it was because of the way testng worked and that there was nothing they could do about it. With very little effort, by reading the TestNG JavaDoc and looking at the surefire code to see that they simply didn't implement the methods that would have kept the behavior the same. This frustrates me and everyone at my company to no end. Slowly, but surely Maven and the ASF are being looked at as software lacking in quality, both within my company and in the Java community as well, as top respected people in the community (who shall remain nameless in this post) "rant" about the errors with maven implementation quite often and speak about how the concept is good, but the implementation has been anything but good and this leads to other conclusions about the way ASF and the Maven project are being run as a whole. This is most unfortunate. This has turn into a "rant" from me, but I think it is worthwhile to have the maven developers hear critical feedback from time to tome. -Original Message- From: P'Simer, Dana (Matrix) [mailto:Dana.P'[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 6:39 AM To: Maven Users List; Maven Developers List Subject: RE: surefire and testng integration issues with surefire-2.4.2 I have recently been dealing with a similar issue. I wanted Junit style reports and did not want to use ant run to run the JunitConverter task, so I added reportng as a test scoped dependency and configured a listener. As an interim solution, you could write a listener that does what you want. It could just be in your src/test/java dir as classes there will be available to TestNG when it is running so there is no need to create a separate jar, unless you want to. To configure it you would do something like this: ... maven-surefire-plugin ... ... listener x.y.z.MyNiftyProgressOutputter ... ... ... The listener properties's value can be a comma separated list of classes so if you have more than one, you can do that. Good Luck, Dana H. P'Simer Dana.P'[EMAIL PROTECTED] -Original Message- From: Jason Chaffee [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 5:32 AM To: Maven Developers List Cc: Maven Users List Subject: surefire and testng integration issues with surefire-2.4.2 I brought this up in the past the maven guys were adamant that they were not able to get per test information to output on the console unless testng changed. I felt all along that this was not correct and I finally had a chance to look into it. Surefire could simply register a listener to get call backs during the execution and could output the results. TestNG does support this functionality with the ITestListener. For example, onStart() will give the start of running a particular class configuration and test methods and onFinish() will be called after all of the configuration and test methods have been run. I took a look at the Surefire code and there is a TestNGReporter that does implement the ITestListener, but it does not implement these methods, they are all no-ops. So, it seems like these could be implemented and then we could see progress output on the console. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
surefire and testng integration issues with surefire-2.4.2
I brought this up in the past the maven guys were adamant that they were not able to get per test information to output on the console unless testng changed. I felt all along that this was not correct and I finally had a chance to look into it. Surefire could simply register a listener to get call backs during the execution and could output the results. TestNG does support this functionality with the ITestListener. For example, onStart() will give the start of running a particular class configuration and test methods and onFinish() will be called after all of the configuration and test methods have been run. I took a look at the Surefire code and there is a TestNGReporter that does implement the ITestListener, but it does not implement these methods, they are all no-ops. So, it seems like these could be implemented and then we could see progress output on the console.
surefire and testng integration issues with surefire-2.4.2
I brought this up in the past the maven guys were adamant that they were not able to get per test information to output on the console unless testng changed. I felt all along that this was not correct and I finally had a chance to look into it. Surefire could simply register a listener to get call backs during the execution and could output the results. TestNG does support this functionality with the ITestListener. For example, onStart() will give the start of running a particular class configuration and test methods and onFinish() will be called after all of the configuration and test methods have been run. I took a look at the Surefire code and there is a TestNGReporter that does implement the ITestListener, but it does not implement these methods, they are all no-ops. So, it seems like these could be implemented and then we could see progress output on the console.
RE: changes to surefire output with testng
I am pretty familiar with testng code, so I would like to look into this further. Is it a correct statement to say that the output we are seeing on the console is coming directly from testng? -Original Message- From: Dan Fabulich [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 3:36 PM To: Maven Developers List Cc: Maven Users List Subject: Re: changes to surefire output with testng Benjamin's links are the right place to start, though I might add that the head of that thread is a really long e-mail from me that doesn't directly address your question. The rest of the thread is about your question. Executive summary: TestNG support was broken in Surefire 2.3.x; it only worked in certain simple cases. In Surefire 2.4 we give more control over to TestNG, fixing the functional errors, but reducing our ability to log, because TestNG doesn't call us back at the right times. There is no option to switch back to the old mostly-broken behavior. If this feature matters (in the linked thread I argue that it doesn't matter very much) then users should pester the TestNG team to provide support for it, by creating an "onClassStart"/"onClassFinish" event that Surefire can use. -Dan Benjamin Bentmann wrote: >> Surefire-2.3.1 used to output which test was running and it would create >> an output file for each test. >> >> I am using testng. Can anyone tell me why this changed and if there is >> any way to configure it to behave in the same manner as previous >> releases? > > Nice to see I am not the only one who is missing that after trying Surefire > 2.4 out... You might want to look at > - http://jira.codehaus.org/browse/SUREFIRE-433 > - > http://www.nabble.com/Test-Suites%2C-Ant%2C-Surefire%2C-and-JunitReport- to15076378.html#a15076378 > > As a workaround, I tried to set forkMode=always to get test-per-class > behavior back but ended again in some discussion: > - http://jira.codehaus.org/browse/SUREFIRE-446 > - > http://www.nabble.com/testng%2C-surefire%2C-and-forkMode%3Dalways-to1532 3782.html > > Regards, > > > Benjamin Bentmann > > > - > 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: changes to surefire output with testng
Hmmm, the bug says it is fixed in 2.4.1 and it still produces a single suite file and single suite output to the console. I agree with you Benjamin, I don't think Dan understood the problem and thus didn't actually fix it. Instead, the fix was for the reporting. -Original Message- From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 3:15 PM To: Maven Developers List; Maven Users List Subject: Re: changes to surefire output with testng Hi, > Surefire-2.3.1 used to output which test was running and it would create > an output file for each test. > > I am using testng. Can anyone tell me why this changed and if there is > any way to configure it to behave in the same manner as previous > releases? Nice to see I am not the only one who is missing that after trying Surefire 2.4 out... You might want to look at - http://jira.codehaus.org/browse/SUREFIRE-433 - http://www.nabble.com/Test-Suites%2C-Ant%2C-Surefire%2C-and-JunitReport- to15076378.html#a15076378 As a workaround, I tried to set forkMode=always to get test-per-class behavior back but ended again in some discussion: - http://jira.codehaus.org/browse/SUREFIRE-446 - http://www.nabble.com/testng%2C-surefire%2C-and-forkMode%3Dalways-to1532 3782.html Regards, Benjamin Bentmann - 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]
changes to surefire output with testng
Surefire-2.3.1 used to output which test was running and it would create an output file for each test. For example, [INFO] [surefire:test] [INFO] Surefire report directory: /usr/local/hudson/workspace/common/common/management/target/surefire-rep orts --- T E S T S --- Running com.foo.management.MBeanTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.279 sec Running com.foo.TomcatServerTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.509 sec Results : Tests run: 10, Failures: 0, Errors: 0, Skipped: 0 Surefire 2.4 and 2.4.1 no longer do this, instead it does the following: [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\tva\server\common\management\targ et\surefire-reports --- T E S T S --- Running TestSuite Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 40.39 sec Results : Tests run: 10, Failures: 0, Errors: 0, Skipped: 0 I am using testng. Can anyone tell me why this changed and if there is any way to configure it to behave in the same manner as previous releases?
RE: where is the source for maven-enforcer-plugin in SVN?
Never mind. I found it under /maven/enforcer. -Original Message- From: Jason Chaffee [mailto:[EMAIL PROTECTED] Sent: Friday, January 25, 2008 11:44 AM To: Maven Developers List Cc: Maven Users List Subject: where is the source for maven-enforcer-plugin in SVN? It doesn't seem to live in maven/plugins/trunk and the latest build 1.0-alpha-3 doesn't have the all of the functionality documented on the site. In particular, it does not support which I would like to use. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
where is the source for maven-enforcer-plugin in SVN?
It doesn't seem to live in maven/plugins/trunk and the latest build 1.0-alpha-3 doesn't have the all of the functionality documented on the site. In particular, it does not support which I would like to use.
RE: [VOTE] Release Maven Surefire version 2.4
FYI, You can compile test classes and still use maven.test.skip=true if you have the compliler plugin configured as followings: org.apache.maven.plugins maven-compiler-plugin 2.0.2 false -Original Message- From: Marat Radchenko [mailto:[EMAIL PROTECTED] Sent: Thursday, December 20, 2007 1:40 AM To: Maven Developers List Subject: Re: [VOTE] Release Maven Surefire version 2.4 Hacks are bad :) Use http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#ski pExec instead. 2007/12/20, Stephen Connolly <[EMAIL PROTECTED]>: > I am concerned by implications of http://jira.codehaus.org/browse/SUREFIRE-350 > > We normally, on development machines, will use "mvn -Dtest=0 clean > install" from the root pom to ensure that all modules have been built > with the latest changes and that those changes compile through all the > subsequent modules and their unit tests before running with the unit > tests (as these are not as fast as they should be and can take an hour > or two) > > This (ok I know it's a hack) will not work for us now. > > maven.test.skip=true will skip compiling the unit tests, so that's no good > > I do not see an easy way out of this... other than the test=0 hack > > On this basis > > -1 > > On Dec 20, 2007 9:21 AM, nicolas de loof <[EMAIL PROTECTED]> wrote: > > +1 > > > > 2007/12/20, Dan Fabulich <[EMAIL PROTECTED]>: > > > > > > > > > > > Hi, > > > > > > Maven Surefire version 2.4 is on the runway. Hopefully folks have spent > > > some time trying out the SNAPSHOT version, because we expect ordinary > > > users to get auto-upgraded to version 2.4 when we decide to release. > > > > > > This version fixes numerous long-outstanding bugs, notably in TestNG > > > support. > > > > > > We solved 71 issues: > > > > > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&styleNa me=Html&version=13243 > > > > > > There are still 31 issues left in JIRA: > > > > > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10541 &status=1 > > > > > > Staging repo: > > > http://people.apache.org/~dfabulich/staging-repo/ > > > > > > Vote open for 72 hours. > > > > > > [ ] +1 > > > [ ] +0 > > > [ ] -1 > > > > > > PS This is my first call for a release. Be gentle. ;-) > > > > > > - > > > 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: need help with a maven 2 plugin
Hmmm, this does not help with how to get the maven-metadata.xml for the current project. Again, there is not a straightforward API on the MavenProject that would allow one to do this. Is there anyway with the Maven API's to gain access to this information within a plugin. I have look at several plugins trying to figure this out and it simply is not straightforward. -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 08, 2007 6:11 AM To: Maven Developers List Subject: RE: need help with a maven 2 plugin You should be able to get most of that from the project object. My suggestion is to look at the maven-help-plugin:effective-pom code since it seems close to what you want. -Original Message- From: Jason Chaffee [mailto:[EMAIL PROTECTED] Sent: Monday, May 07, 2007 7:37 PM To: dev@maven.apache.org Subject: FW: need help with a maven 2 plugin FYI, I have not gotten any help on the users list and I image at least one contributor will know how to do what I want to do below within the context of a plugin. I would like to create a "build-report-plugin" that is able to report on the versions, timestamps, artifact types, build numbers, and so on. I can write my own custom code to do all of this, but there there has to be an easier way to reuse the code/components that maven is already using to download/upload the metadata files. It seems logical from an OO perspective that the MavenProject object would have a method that could do something like this, but I could not find one. Does anyone know how what objects to use and how to get a reference to them in the plugin itself? Thanks. - 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]
FW: need help with a maven 2 plugin
FYI, I have not gotten any help on the users list and I image at least one contributor will know how to do what I want to do below within the context of a plugin. I would like to create a "build-report-plugin" that is able to report on the versions, timestamps, artifact types, build numbers, and so on. I can write my own custom code to do all of this, but there there has to be an easier way to reuse the code/components that maven is already using to download/upload the metadata files. It seems logical from an OO perspective that the MavenProject object would have a method that could do something like this, but I could not find one. Does anyone know how what objects to use and how to get a reference to them in the plugin itself? Thanks. - 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]
FW: maven-2.0.6 throws NPE in surefire
Carlos, this seems to be the same issue with surefire forking and you
previously mentioned that it was because the wrong version of surefire
was being used. Which version should be used with 2.0.6?
-Original Message-
From: Jason Chaffee [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 01, 2007 3:56 PM
To: Maven Users List
Subject: RE: maven-2.0.6 throws NPE in surefire
It is version 2.3 and the same version was used in both maven-2.0.5 and
maven-2.0.6. However, only maven-2.0.6 produces the NPE. Seems like
there was bug introduced in maven-2.0.6.
Also, I had a clean repo for each version of maven to make sure the
correct versions of the dependencies were being used by each version of
maven.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Sunday, April 01, 2007 2:54 PM
To: Maven Users List
Subject: Re: maven-2.0.6 throws NPE in surefire
what version of maven-surefire-plugin?
try setting the version explicitly
On 4/1/07, Jason Chaffee <[EMAIL PROTECTED]> wrote:
> This works fine in maven-2.0.5.
>
> I have the following surefire configuration:
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> once
>
>
-javaagent:${project.build.directory}/test-lib/aspectjweaver.ja
> r -Xmx256m
>
>
>
> I get this error in 2.0.6
>
> [INFO] [surefire:test]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.artifact.DefaultArtifact.getSelectedVersion(DefaultA
> rtifact.java:582)
> at
> org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBoot
> er(SurefirePlugin.java:490)
> at
> org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi
> n.java:391)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:143)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
FW: maven-2.0.6 throws NPE in surefire
-Original Message-
From: Jason Chaffee [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 01, 2007 1:06 PM
To: Maven Users List
Subject: maven-2.0.6 throws NPE in surefire
This works fine in maven-2.0.5.
I have the following surefire configuration:
org.apache.maven.plugins
maven-surefire-plugin
once
-javaagent:${project.build.directory}/test-lib/aspectjweaver.ja
r -Xmx256m
I get this error in 2.0.6
[INFO] [surefire:test]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.artifact.DefaultArtifact.getSelectedVersion(DefaultA
rtifact.java:582)
at
org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBoot
er(SurefirePlugin.java:490)
at
org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi
n.java:391)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:143)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
-
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]
what is the status of testng in surefire?
I know there was a testng branch created more than a month ago but there hasn't been an update and I would really prefer to use testng. Thanks, Jason
