Re: perm denied for deploying 2.4-SNAPSHOT of surefire
Yeah I've got it "mostly" working now with manual metadata removals. On a side note - it looks like the permissions get written out correctly by default when I locally modify the snapshotrepo distribution url to use scpexe:// instead of relying on whatever the default is. (which doesn't honor group write perms by default I guess) On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: only jason can do the chmod or even better run /www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh if you want to fix it in the meantime, download the metadata files, delete them in the server and upload again, then run /www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > Thanks Carlos! > > Seems that this has happened in more than one place (and is also strangely > the default behavior of my deploy - though when I do it with tapestry on the > same repo it doesn't even ask for my password as I've done the shared ssh > key thing ) . > > Any chance you could chmod -R g+w everything under surefire ? > > On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > > > i just fixed the permissions, it was owned by jason with no group > > perms, but as the directory is group writable you can delete them and > > copy again, changing permissions > > > > On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > > While attempting to deploy the new 2.4 snapshot version of surefire I > > got > > > somewhat far and then ran into a perm denied for one of the metadata > > files: > > > > > > [ERROR] BUILD ERROR > > > [INFO] > > > > > > [INFO] Error installing artifact's metadata: Error while deploying > > metadata: > > > SCP terminated with error: 'scp: > > > > > /www/people.apache.org/repo/m2-snapshot-repository/org/apache/maven/surefire/surefire/2.4-SNAPSHOT/maven- > > > metadata.xml: Permission denied' > > > > > > I just ran all the tests against various testng based maven projects > > for > > > both 5.1 / 5.5 versions of testng and everything is a-ok and ready to go > > > from a clean checkout of: > > > > > > > > https://svn.apache.org/repos/asf/maven/sandbox/branches/surefire/surefire-collaboration > > > > > > If anyone else is able to either deploy it for me or add me to the right > > > groups it'd be much appreciated. > > > > > > (my current group perms on people.apache.org are :) > > > > > > uid=2202(jkuhnert) gid=2202(jkuhnert) groups=2202(jkuhnert), > > 5000(apcvs), > > > 5004(jakarta), 5035(tapestry) > > > > > > -- > > > Jesse Kuhnert > > > Tapestry/Dojo team member/developer > > > > > > Open source based consulting work centered around > > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > > > > > > > > > -- > > I could give you my word as a Spaniard. > > No good. I've known too many Spaniards. > > -- The Princess Bride > > > > > > -- > Jesse Kuhnert > Tapestry/Dojo team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: perm denied for deploying 2.4-SNAPSHOT of surefire
nevermind, I get it nowam trying a new deploy now On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: Thanks Carlos! Seems that this has happened in more than one place (and is also strangely the default behavior of my deploy - though when I do it with tapestry on the same repo it doesn't even ask for my password as I've done the shared ssh key thing ) . Any chance you could chmod -R g+w everything under surefire ? On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED] > wrote: > > i just fixed the permissions, it was owned by jason with no group > perms, but as the directory is group writable you can delete them and > copy again, changing permissions > > On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > While attempting to deploy the new 2.4 snapshot version of surefire I > got > > somewhat far and then ran into a perm denied for one of the metadata > files: > > > > [ERROR] BUILD ERROR > > [INFO] > > > > > [INFO] Error installing artifact's metadata: Error while deploying > metadata: > > SCP terminated with error: 'scp: > > > /www/people.apache.org/repo/m2-snapshot-repository/org/apache/maven/surefire/surefire/2.4-SNAPSHOT/maven- > > metadata.xml: Permission denied' > > > > I just ran all the tests against various testng based maven projects > for > > both 5.1 / 5.5 versions of testng and everything is a-ok and ready to > go > > from a clean checkout of: > > > > > https://svn.apache.org/repos/asf/maven/sandbox/branches/surefire/surefire-collaboration > > > > If anyone else is able to either deploy it for me or add me to the > right > > groups it'd be much appreciated. > > > > (my current group perms on people.apache.org are :) > > > > uid=2202(jkuhnert) gid=2202(jkuhnert) groups=2202(jkuhnert), > 5000(apcvs), > > 5004(jakarta), 5035(tapestry) > > > > -- > > Jesse Kuhnert > > Tapestry/Dojo team member/developer > > > > Open source based consulting work centered around > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: perm denied for deploying 2.4-SNAPSHOT of surefire
Thanks Carlos! Seems that this has happened in more than one place (and is also strangely the default behavior of my deploy - though when I do it with tapestry on the same repo it doesn't even ask for my password as I've done the shared ssh key thing ) . Any chance you could chmod -R g+w everything under surefire ? On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: i just fixed the permissions, it was owned by jason with no group perms, but as the directory is group writable you can delete them and copy again, changing permissions On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > While attempting to deploy the new 2.4 snapshot version of surefire I got > somewhat far and then ran into a perm denied for one of the metadata files: > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error installing artifact's metadata: Error while deploying metadata: > SCP terminated with error: 'scp: > /www/people.apache.org/repo/m2-snapshot-repository/org/apache/maven/surefire/surefire/2.4-SNAPSHOT/maven- > metadata.xml: Permission denied' > > I just ran all the tests against various testng based maven projects for > both 5.1 / 5.5 versions of testng and everything is a-ok and ready to go > from a clean checkout of: > > https://svn.apache.org/repos/asf/maven/sandbox/branches/surefire/surefire-collaboration > > If anyone else is able to either deploy it for me or add me to the right > groups it'd be much appreciated. > > (my current group perms on people.apache.org are :) > > uid=2202(jkuhnert) gid=2202(jkuhnert) groups=2202(jkuhnert), 5000(apcvs), > 5004(jakarta), 5035(tapestry) > > -- > Jesse Kuhnert > Tapestry/Dojo team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
perm denied for deploying 2.4-SNAPSHOT of surefire
While attempting to deploy the new 2.4 snapshot version of surefire I got somewhat far and then ran into a perm denied for one of the metadata files: [ERROR] BUILD ERROR [INFO] [INFO] Error installing artifact's metadata: Error while deploying metadata: SCP terminated with error: 'scp: /www/people.apache.org/repo/m2-snapshot-repository/org/apache/maven/surefire/surefire/2.4-SNAPSHOT/maven- metadata.xml: Permission denied' I just ran all the tests against various testng based maven projects for both 5.1 / 5.5 versions of testng and everything is a-ok and ready to go from a clean checkout of: https://svn.apache.org/repos/asf/maven/sandbox/branches/surefire/surefire-collaboration If anyone else is able to either deploy it for me or add me to the right groups it'd be much appreciated. (my current group perms on people.apache.org are :) uid=2202(jkuhnert) gid=2202(jkuhnert) groups=2202(jkuhnert), 5000(apcvs), 5004(jakarta), 5035(tapestry) -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: deploy surefire-collab 2.4-SNAPSHOT?
Ok maybe there is a tiny problem, not sure who / where it should go but I have a real project setup thusly: parent pom -> - ) defines build plugin dependency on maven-surefire-plugin 2.4-SNAPSHOT -) defines dependency on TestNG 5.1 child pom -> -) has a area defined but not explicit maven-surefire-plugin or testng dependency defined When running a simple "mvn clean install" it gets a null pointer trying to resolve the selected version of testng: [INFO] [surefire:test] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.artifact.DefaultArtifact.getSelectedVersion(DefaultArtifact.java:582) at org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBooter(SurefirePlugin.java:490) It works fine on my other computer that uses maven 2.0.5 but seems to fail with 2.0.6. Like I said, I don't know what the problem is for sure but I'm also not sure how to fix it in surefire as it's in an api not covered there. On 4/11/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: No not expecting any problems, just wanted to make sure I was following policy. Thanks. On 4/11/07, Brett Porter <[EMAIL PROTECTED]> wrote: > are you expecting it to be problematic? I think including it in the > current set is fine. > > - Brett -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: Maven and Fedora
state == "%post":
>>> if currentpackage is not None \
>>> and currentpackage.contains_jars():
>>> add_rebuild_gcj_db()
>>> currentpackage.set_post_done()
>>> elif state == "%postun":
>>> if currentpackage is not None \
>>> and currentpackage.contains_jars():
>>> add_rebuild_gcj_db()
>>> currentpackage.set_postun_done()
>>>
>>> def set_currentpackage(line):
>>> global currentpackage
>>>
>>> fields = line.split()
>>> if len(fields) == 1:
>>> if not mainpackageempty:
>>> try:
>>> currentpackage = packages[mainpackagename]
>>> except KeyError, e:
>>> pass
>>> else:
>>> currentpackage = None
>>> else:
>>> if fields[1] == "-n":
>>> # full name specified
>>> try:
>>> currentpackage = packages[fields[2]]
>>> except KeyError, e:
>>> pass
>>> else:
>>> try:
>>> currentpackage = packages[mainpackagename + "-" + fields[1]]
>>> except KeyError, e:
>>> pass
>>>
>>> def set_macroized_package_names():
>>> global macroizedpackagenames
>>>
>>> packagelines = os.popen("cat " + specfilename + " | grep '^%
>>> package'")
>>> packagenames = os.popen("rpm -q --specfile --queryformat='%{name}
>>> \n' " + specfilename + " | grep -v " + mainpackagename + "-
>>> debuginfo")
>>>
>>> packageline = packagelines.readline()
>>> # skip main package name
>>> packagename = packagenames.readline()
>>> packagename = packagenames.readline()
>>>
>>> if packagename != "":
>>> while packageline != "":
>>> fields = packageline.split()
>>> if len(fields) == 2:
>>> macroizedpackagenames[packagename.strip()] = mainpackagename +
>>> "-" + fields[1]
>>> else:
>>> if len(fields) == 3:
>>> macroizedpackagenames[packagename.strip()] = fields[2]
>>> packageline = packagelines.readline()
>>> packagename = packagenames.readline()
>>>
>>> packagelines.close()
>>> packagenames.close()
>>>
>>> if packageline != "" or packagename !="":
>>> raise Error, "number of Name: and %package lines does not match
>>> number of names returned by spec file query"
>>> else:
>>> print "macroized package names creation passed"
>>>
>>> print "map of unmacroized names to macroized names:"
>>> print macroizedpackagenames
>>>
>>> def next_state(line):
>>> global state
>>> if line == "":
>>> add_to_part(state)
>>> state = "END"
>>> return
>>> for part in partList:
>>> if line.startswith(part):
>>> add_to_part(state)
>>> state = part
>>> add_before_part(state)
>>> set_currentpackage(line)
>>>
>>> def print_version():
>>> print NAME, VERSION
>>> sys.exit(0)
>>>
>>> def print_usage():
>>> print "Usage: " + NAME + " SRPM RPMS"
>>> print "Create a JPackage spec file that contains GCJ support from
>>> a JPackage"
>>> print "SRPM and its corresponding RPMs. " + NAME + " uses the
>>> binary RPMs"
>>> print "to determine each sub-package's list of jar files."
>>> print ""
>>> print "Example:"
>>> print " " + NAME + " ~/rpmbuild/SRPMS/bsh-*1.3.0-6jpp* ~/rpmbuild/
>>> RPMS/noarch/bsh-*1.3.0-6jpp*"
>>> sys.exit(0)
>>>
>>> if __name__ == "__main__":
>>> try:
>>>
>>> options = sys.argv[1:]
>>>
>>> if len(options) == 0:
>>> print NAME + ": no input files"
>>> print_usage()
>>>
>>> origdir = os.getcwd()
>>>
>>> # find SRPM within arguments
>>> srpmfilename = ""
>>> rpmfilenames = []
>>> for option in options:
>>> if option.endswith(".src.rpm"):
>>> if srpmfilename != "":
>>> raise Error, "more than one SRPM specified"
>>> else:
>>> srpmfilename = os.path.join(origdir, option)
>>> elif option.endswith(".rpm"):
>>> rpmfilenames.append(os.path.join(origdir, option))
>>> elif option == "--version":
>>> print_version()
>>> elif option == "--help":
>>> print_usage()
>>>
>>> warnings.filterwarnings("ignore", message="tmpnam is a potential
>>> security risk to your program")
>>> tmpdir = os.path.basename(os.tmpnam())
>>> os.mkdir(tmpdir)
>>> os.chdir(tmpdir)
>>>
>>> # get spec file name: assumes that the spec file is called
>>> # %{name}.spec
>>> print "processing: " + srpmfilename
>>> mainpackagename = get_package_name(srpmfilename)
>>> specfilename = mainpackagename + ".spec"
>>>
>>> # extract spec file
>>> print "extracting spec file: " + specfilename
>>> extract_files(srpmfilename, specfilename)
>>>
>>> # check for existing gcj support
>>> checkconverted = os.popen("grep gcj_support " + specfilename)
>>> checksupport = checkconverted.readline()
>>> if checksupport != "":
>>> raise Error, "these rpms already support gcj"
>>> status = checkconverted.close()
>>> if status is None:
>>> raise Error, "failed to close grep pipe"
>>> else:
>>> print "no gcj support detected"
>>>
>>> # calculate unmacroized name-to-macroized name mapping
>>> set_macroized_package_names()
>>>
>>> for rpmfilename in rpmfilenames:
>>> note_package(rpmfilename)
>>>
>>> # open spec file for reading
>>> specfile = open(specfilename, 'r')
>>>
>>> # open output spec file for writing
>>> outputspecfile = open(os.path.join(origdir, mainpackagename + "-
>>> gcj.spec"), 'w')
>>>
>>> # check if there is a main package or only sub-packages
>>> if mainpackagename in packages:
>>> currentpackage = packages[mainpackagename]
>>> else:
>>> mainpackageempty = True
>>>
>>> print "main package:", currentpackage
>>>
>>> line = specfile.readline()
>>> next_state(line)
>>>
>>> # skip license block
>>> while line.startswith("#"):
>>> outputspecfile.write(line)
>>> line = specfile.readline()
>>>
>>> outputspecfile.write("\n%define gcj_support %{?_with_gcj_support:
>>> 1}%{!?_with_gcj_support:%{?_without_gcj_support:0}%{!?
>>> _without_gcj_support:%{?_gcj_support:%{_gcj_support}}%{!?
>>> _gcj_support:0}}}\n")
>>>
>>> while line != "":
>>> if state == "PREAMBLE":
>>> filter_preamble(line)
>>> else:
>>> outputspecfile.write(line)
>>>
>>> line = specfile.readline()
>>> next_state(line)
>>>
>>> outputspecfile.close()
>>>
>>> os.chdir(origdir)
>>>
>>> except Error, e:
>>> print >> sys.stderr, "%s: error: %s" % (
>>> os.path.basename(sys.argv[0]), e)
>>> sys.exit(1)
>>>
>>>
>>>
>>> -
>>> 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]
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
I personally have never trusted any linux based package manager to install any java software, maybe that's just me being paranoid.. That being said, I have observed many users referencing having installed ant via on linux in the dojo users list. As long as the maven devs don't have to maintain the distros (I can't imagine how painful it would be, and if you are going to do it let's not forget those of us using debian based packages - ubuntu is gaining quite a bit of ground these days) it seems like it might possibly be beneficial to enough "average joe" users to warrant further inspection. On 12/6/06, Carl Trieloff <[EMAIL PROTECTED]> wrote: The point is to try use maven to build Java pieces in OS distros which should be a good thing. Carl. -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.x release
Exactly... Trying to quantify the stability of a release before it goes out the door is just impossible/not practical for os. Release early & often. ;) On 12/4/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote: what I see is that there's always issues that anyone wants to get fixed and that makes the releases take forever. If things are not critical imho is more important to release often and move issues to 1.1.1 On 12/4/06, Stephane Nicoll <[EMAIL PROTECTED]> wrote: > Hi, > > According to the roadmap [1], there's 25 issues left. Mostly plugin upgrades > which could come quite quickly and at least 1755 and 1789. The problem is > that we're trying to release RC1 and it makes not much sense if we have > still open issues scheduled for 1.1 > > Cheers, > Stéphane > > > > [1] > http://jira.codehaus.org/browse/MAVEN?report=com.atlassian.jira.plugin.system.project:roadmap-panel > > On 12/5/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > Hi Guys, > > > > What's left to do before the M1 release can go out? We need to get > > the Maven 1.x repository usage off Ibiblio. > > > > Jason. > > > > - > > 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] -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse plugin disambiguation
I'm not sure what problem he is having/why. The plugin page is pretty easy
to follow: http://maven.apache.org/eclipse-plugin.html
Add http://m2eclipse.codehaus.org/ to your eclipse update manager and you're
done. (besides the fact that you also need to install maven2 , which may be
the part he is missing... :/ )
On 11/12/06, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:
No, what he is asking is: "could somebody please explain calmly and
clearly to me what the status is of support for Maven inside eclipse
". Which eclipse plugins are available, which should I use, which are
defunct, and where are they really (the project, the source, the
eclipse update site)?
On 12 Nov 2006, at 22:36, Nathan Beyer wrote:
> It seems like you're asking "How do I build XML-RPC inside of the
> Eclipse IDE?", which is probably best asked on an XML-RPC list, not
> the Maven developer's list.
>
> The XML-RPC project uses Maven 2 for their builds, much like other
> project would use an Ant script (or scripts). As such, if you want to
> build it like the project does for releases and testing, then you'll
> need to use Maven 2, much like another project would require you to
> use Ant. So, to answer the first question, yes, you must install Maven
> 2 to build this code.
>
> However, you can circumvent the build scripts and just checkout the
> code, create an Eclipse project where you checked out the code, setup
> the classpath for the Eclipse project and try to put together the
> pieces to yourself using the documentation from the XML-RPC web site.
>
> What I would suggest though is install Maven 2, check out the code,
> run the build to make sure you can recreate that (run a "mvn verify"
> command). Once you can successfully build that, then run the goal "mvn
> eclipse:eclipse" to generate all of the Eclipse project artifacts and
> open Eclipse and import the projects ("Existing projects").
>
> -Nathan
>
>
> On 11/12/06, techtonik <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> Can anybody clarify Eclipse 2 Maven relations? As a person far from
>> Maven development, I am quite confused about all the stuff around it.
>> What I would like is to enter some URL as Eclipse update site,
>> install
>> what is available and compile SVN version of
>> http://ws.apache.org/xmlrpc/ used it my project
>>
>> That doesn't work. Seems like I need to install Maven manually and
>> use
>> it. The history:
>>
>>
>> Mergere Maven 2.x Plugin
>> - site http://m2eclipse.codehaus.org/ is outdated. Latest version
>> listed - 0.0.5, actual 0.0.9.
>> - broken link for source code -
>> http://svn.codehaus.org/trunk/?root=m2eclipse (actual is
>> http://svn.m2eclipse.codehaus.org/)
>> - bugs, a lot of unresolved bugs - http://jira.codehaus.org/browse/
>> MNGECLIPSE
>> - so unable to use https://issues.apache.org/jira/browse/XMLRPC-123
>>
>> Maven 2.x Eclipse Plugin
>> - http://jira.codehaus.org/browse/MECLIPSE - just no install link
>> to try
>>
>> MavenIDE
>> - http://mevenide.codehaus.org/mevenide-ui-eclipse/faq.html - 404
>> links
>> - eclipse update site found lists only Maven 1.0.2
>> - after installation it was not able to validate pom.xml file from
>> checkout odhttp://svn.apache.org/repos/asf/webservices/xmlrpc/
>> branches/XMLRPC_3_0_BRANCH
>> Severity and DescriptionPathResource
>> LocationCreation Time Id
>> cvc-complex-type.2.4.a: Invalid content starting with element
>> 'inceptionYear'. One of '{"":organization}' is
>> expected. ws-xmlrpc pom.xml line 8 1163327720343 18941
>> cvc-complex-type.2.4.b: The content of element 'mailingList' is not
>> complete. One of '{"":subscribe}' is expected. ws-xmlrpc
>> pom.xml line
>> 13 1163327720359 18942
>>
>> I was unable to execute the build in Eclipse - I just do not have
>> enough experience to say what I need to build the project. Attached
>> you will find error log for MevenIDE behavior in Eclipse 3.2
>>
>>
>> --
>> --t.
>>
>>
>>
>> -
>> 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]
>
"[…] my biggest problem is finding out how to do things."
(in a mail on the Maven Users List)
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
website "ui updates" ?
An utterly useless observation I know, but are you guys "trying" to make the site look worse on purpose? Compare: http://maven.apache.org to Duplicate of (original maven theme): http://tapestry.apache.org Just thought I'd say something cause it was so noticeable.. -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: Moving surefire plugin to surefire
Awesome! Does what you said earlier mean that you intend to hook up more of the unit tests (like the old integration tests under the maven-surefire-plugin dir ) into the core surefire build? If so, please feel free to count on support from me on making sure the TestNG portions are handled as well as can be done. (I'm not sure if it's even possible to use a 1.5 jre for one set of tests and a 1.4 jre for another in an automated sort of way . ) I'll make sure I send my last remaining patches tomorrow. If there is a better way to make sure you know where they are other than a jira issue let me know. On 9/24/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: On 24 Sep 06, at 4:39 PM 24 Sep 06, Jesse Kuhnert wrote: > Will tomorrow be too late to send in a tiny set of outstanding > patches for > surefire before you do that? > Nope, I'll just be getting started this week so I doubt it will be released this week. It will take me a couple days to look at the code and patches that are around. > On 9/24/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: >> >> This seemed to be the general consensus with some of the other >> project setups like Archetype where all the code is together: the >> core, all modules and the Maven plugin. I'm going to start working on >> the release of the surefire plugin so I figure I might as line put >> all the surefire code in one place. >> >> +1 >> >> Jason van Zyl >> [EMAIL PROTECTED] >> >> >> >> >> --------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Jesse Kuhnert > Tapestry/Dojo/(and a dash of TestNG), team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: Moving surefire plugin to surefire
Will tomorrow be too late to send in a tiny set of outstanding patches for surefire before you do that? On 9/24/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: This seemed to be the general consensus with some of the other project setups like Archetype where all the code is together: the core, all modules and the Maven plugin. I'm going to start working on the release of the surefire plugin so I figure I might as line put all the surefire code in one place. +1 Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: Status of maven-surefire-plugin & TestNG
I changed things to make it work with jdk14 tests...I haven't sent any patches to maven to make these work again yet. On 9/3/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Nope :-( rm -rf ~/.m2/repository/org/apache/maven/surefire rm -rf ~/.m2/repository/org/apache/maven/plugins/maven-surefire-plugin w/2.3-SNAPSHOT: --- T E S T S --- Running org.apache.geronimo.testsuite.console.SimpleLoginTest Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec Running org.apache.geronimo.testsuite.console.LinkCheckTest Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec w/2.8-SNAPSHOT: --- T E S T S --- Running org.apache.geronimo.testsuite.console.SimpleLoginTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.301 sec Running org.apache.geronimo.testsuite.console.LinkCheckTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.669 sec --jason On Sep 3, 2006, at 5:42 AM, Fabrizio Giustina wrote: > On 9/3/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> rm -rf ~/.m2/repository/org/apache/maven/plugins/maven-surefire- >> plugin/ > > the bug is in surefire-booter, do a: > > rm -rf ~/.m2/repository/org/apache/maven/surefire/surefire-booter/ > > > ... and it will work > > fabrizio > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: http://jira.codehaus.org/browse/SUREFIRE-53
P.S. I'll try and send the latest set of patches in the next day or so. They make the jdk14 based javadoc tests work again. On 9/3/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: Great! Sorry for thinking your patch was the culprit then ;) The biggest issue seems to be that you can't allow a test class to get loaded up into the class loader unless the provider (ie testng) classes are also loaded up first...This is because the test class may actually instantiate properly, but without the annotation definitions in the testng.jar none of the annotations will be found. (Ie you can't call Method.getAnnotation(Test.class) and have it not be null) I am glad you are depending on it now as well :) I have a few other changes that I've started to lose track of since last uploading those patches. It's also been a couple months (little over I think) now since the problem first came about, so it's easy to see why the community might be grumpy. I know I'm able to fix and deploy tapestry bug fixes via the new whizbang maven2 snapshot repos now. For the testng developers, where if bugs are found they are almost immediately responded to with same/next day fixes I'm starting to look like the black sheep leaving all of our maven2 users broken for months on end... On 9/3/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: > > Hi Jesse, > > first of all thanks for your patches for the surefire TestNG provider > and for your help here... I recently moved to TestNG for a couple of > projects and I will definitively try to make surefire support more > robust. > > I committed a few long standing patches, but the commit for > http://jira.codehaus.org/browse/SUREFIRE-53 it's probably not the > culprit for the problems you see (that patch just assure that the > original classloader gets reset after running surefire). > > So that should depend on a previous change by Kenney: > > http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SurefireBooter.java?r1=427040&r2=438999&diff_format=h > > This was the comment: "Set parent classloader to null for the > testsClassLoader. > If this is not done, the System classloader is added, in this case an > AppClassloader containing everything in the root classpath. For > instance, in maven, everything in core/ is available.This can cause > clashes with the plexus-utils used in maven itself." > > So looks like there was a different reason for doing that... but we > could rethink at it if it brokes more than what it fixes. > I just realized that this actually broke my projects using TestNG, > although the tests in the surefire testng provider work fine. > I'll try to reproduce this behaviour in a test, then we will try to > understand how to definitively fix it: any help will be appreciated, > and I promise that patches will not stay waiting in Jira for long > anymore... > > > fabrizio > > > > On 9/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > Applying the patch mentioned has made running annotation based testng > tests > > b0rken. Ie before it was loading classes using a context of system > class > > loader. I've fixed this locally by calling > createClassLoader(classpathurls, > > childdelegation, true) (which uses system class loader by default) > instead > > of createClassLoader(classpathurls, null, childdelegation, true). > > > > The recent application of old patches is definitely appreciated, but > things > > like this make me nervous for the future. There ~has~ to be a > reasonable way > > to run unit tests against surefire that assert things aren't > broken...The > > logic of classloader dependencies is too fragile to not have tests... > > > > Sorry, I shouldn't be telling you guys what to do.. > > > > -- > > Jesse Kuhnert > > Tapestry/Dojo/(and a dash of TestNG), team member/developer > > > > Open source based consulting work centered around > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > > > > > > --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: http://jira.codehaus.org/browse/SUREFIRE-53
Great! Sorry for thinking your patch was the culprit then ;) The biggest issue seems to be that you can't allow a test class to get loaded up into the class loader unless the provider (ie testng) classes are also loaded up first...This is because the test class may actually instantiate properly, but without the annotation definitions in the testng.jar none of the annotations will be found. (Ie you can't call Method.getAnnotation(Test.class) and have it not be null) I am glad you are depending on it now as well :) I have a few other changes that I've started to lose track of since last uploading those patches. It's also been a couple months (little over I think) now since the problem first came about, so it's easy to see why the community might be grumpy. I know I'm able to fix and deploy tapestry bug fixes via the new whizbang maven2 snapshot repos now. For the testng developers, where if bugs are found they are almost immediately responded to with same/next day fixes I'm starting to look like the black sheep leaving all of our maven2 users broken for months on end... On 9/3/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: Hi Jesse, first of all thanks for your patches for the surefire TestNG provider and for your help here... I recently moved to TestNG for a couple of projects and I will definitively try to make surefire support more robust. I committed a few long standing patches, but the commit for http://jira.codehaus.org/browse/SUREFIRE-53 it's probably not the culprit for the problems you see (that patch just assure that the original classloader gets reset after running surefire). So that should depend on a previous change by Kenney: http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SurefireBooter.java?r1=427040&r2=438999&diff_format=h This was the comment: "Set parent classloader to null for the testsClassLoader. If this is not done, the System classloader is added, in this case an AppClassloader containing everything in the root classpath. For instance, in maven, everything in core/ is available.This can cause clashes with the plexus-utils used in maven itself." So looks like there was a different reason for doing that... but we could rethink at it if it brokes more than what it fixes. I just realized that this actually broke my projects using TestNG, although the tests in the surefire testng provider work fine. I'll try to reproduce this behaviour in a test, then we will try to understand how to definitively fix it: any help will be appreciated, and I promise that patches will not stay waiting in Jira for long anymore... fabrizio On 9/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > Applying the patch mentioned has made running annotation based testng tests > b0rken. Ie before it was loading classes using a context of system class > loader. I've fixed this locally by calling createClassLoader(classpathurls, > childdelegation, true) (which uses system class loader by default) instead > of createClassLoader(classpathurls, null, childdelegation, true). > > The recent application of old patches is definitely appreciated, but things > like this make me nervous for the future. There ~has~ to be a reasonable way > to run unit tests against surefire that assert things aren't broken...The > logic of classloader dependencies is too fragile to not have tests... > > Sorry, I shouldn't be telling you guys what to do.. > > -- > Jesse Kuhnert > Tapestry/Dojo/(and a dash of TestNG), team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > > --------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
http://jira.codehaus.org/browse/SUREFIRE-53
Applying the patch mentioned has made running annotation based testng tests b0rken. Ie before it was loading classes using a context of system class loader. I've fixed this locally by calling createClassLoader(classpathurls, childdelegation, true) (which uses system class loader by default) instead of createClassLoader(classpathurls, null, childdelegation, true). The recent application of old patches is definitely appreciated, but things like this make me nervous for the future. There ~has~ to be a reasonable way to run unit tests against surefire that assert things aren't broken...The logic of classloader dependencies is too fragile to not have tests... Sorry, I shouldn't be telling you guys what to do.. -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: how to get current settings object
Thanks for all the hard work on this Daniel, I promise I'll add your changes lickety split once this is all squared away ;) (or possibly find some way to make this a tiny sub-project...we shall see) On 8/28/06, gredler <[EMAIL PROTECTED]> wrote: Hi Jason, Thanks for the response. I'm not aware of any license clickthrough libraries, so I wrote my own handler (one class) which resides in maven-artifact. I'm not sure how coupling it to maven-artifact precludes developers who are embeding maven-artifact from exploiting this capability? Or did you mean *not* want this capability? Anyways, my mention of Maven CLI and the other subprojects were just me trying to list the places I have been looking for examples of how to retrieve a reference to the current Settings instance. That's my main problem now: how do I get the Settings instance and persist a change to it. If you are able to take a couple of minutes to review the patches, please post any suggestions to the JIRA issue. This is my first Maven customizaton, so be gentle ;-) Regards, Daniel On 28 Aug 06, at 6:15 PM 28 Aug 06, gredler wrote: > > Hi, > > I'm working on the license clickthough functionality in the artifact > resolver (http://jira.codehaus.org/browse/MNG-671), and I need to > know: > > - what the best way of retrieving the current Settings object is > - what the best way of saving changes to the Settings object is > > I'm hoping that I can just add a line or two to a components.xml > file and > have Maven automagically wire the object up. > > I've been banging my head against MavenSettingsBuilder (recently > refactored), MavenTools, MavenEmbedder, etc. There has to be a > simple way to > do this behind all the abstractions! > Do you have a general click through library that you are binding in with a resolution listener or is this stuff coupled to maven-artifact? I will respond further once I look at the patches, but what you should have is a separate library bridge in with a listener and any configuration you need should be couched in terms of maven-artifact requests translated to what your library needs. Because people may simply embed maven-artifact and want this capability. Maybe you did this, but this is the only way I see this working. Shouldn't matter what the Maven CLI does. > Thanks, > > Daniel -- View this message in context: http://www.nabble.com/how-to-get-current-settings-object-tf2180267.html#a6030399 Sent from the Maven Developers forum at Nabble.com. ----- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: Please sync Apache m2 repository for Struts
Do I need to do this for Tapestry as well? I was under the impression scripts came along and did it magically for me. On 8/16/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: Please sync repo/m2-ibiblio-rsync-repository/org/apache/struts with ibiblio. Struts 1.3.5 Beta has been deployed with signatures. Release vote: http://www.nabble.com/-VOTE--Struts-1.3.5-Quality-%28re-vote%29-t2057958.html Thanks, Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: [vote] Release Maven 1.1 beta 3
+1 non-binding On 7/29/06, Dion Gillard <[EMAIL PROTECTED]> wrote: +1 non binding. On 7/30/06, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > Hi folks, > > Please vote on releasing Maven 1.1 Beta 3. > Since the beta 2 we upgraded almost all plugins and deprecated some of them > [1]. > We prepared a release note [2] to summarize changes on the core and deployed > a snapshot [3] to allow you to test it. > > I take the opportunity of this email to thank all of those who worked on > this release, and particularly Lukas who did the major part of the work. > > Vote closes in 72 hours. > > +1 from me. > > Arnaud > > [1] http://maven.apache.org/maven-1.x/plugins/bundledHistory.html > [2] http://maven.apache.org/maven-1.x/start/release-notes-1.1-beta-3.html > [3] > http://people.apache.org/repo/m1-snapshot-repository/maven/distributions/20060729/ > > -- http://www.multitask.com.au/people/dion/ "If you even dream of beating me you'd better wake up and apologize" - Muhammad Ali - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
surefire javascript provider?
I feel a little sheepish even suggesting it, but since I plan on moving a little ant task I created over to a maven2 plugin for this purpose I thought I'd ask just in case. The unit tests are written in javascript and executed via the java rhino ( http://www.mozilla.org/rhino/) runtime (which was partially implemented by Brendan Eich as well, the javascript creator). I originally stole some of the infrastructure for this from http://dojotoolkit.org, which I think got it from http://burstproject.org/ . The java code portion has been coded in a similar fashion to the core TestNG base, so I think it will be an easy fit to pop into surefire. It's imperfect in that there is no real "window" object, but with a little work "mocking" up js objects it's not really that hard to cover the 80% use case. It's pretty simple and does a good job doing what it is intended to do. (ie not anything comparable to what projects like htmlunit are trying to do with rhino ). I'd have to refactor a couple things to remove the dependency on dojo javascript runtime functions but don't foresee that being too much of an issue. For examples of how the current ant task / unit tests look see http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/js/. -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: Who can deploy what, when and how?
I have no idea what the various policies are or even if I'm correct about the functionality, but the following pom works for me deploying snapshot builds. http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/pom.xml?view=markup I think the combination of having a distributionManagement section with a snapshotRepository + the version ending with -SNAPSHOT should trigger the deploy to go to the snapshots repo. I do it with "mvn deploy". On 7/16/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Hi all Since I'm new here as a committer, I have a couple of questions regarding deployment. 1. The main Maven site Is any committer allowed to deploy (or publish) the site at any time? What's the procedure for doing that? Do you just check out the latest from svn and do: mvn site-deploy Are there any special prerequisites, like what version of Maven and the site plugin to use, that you must fulfill before you do it? Perhaps some bits to put in your settings.xml. 2. A Maven plugin site Same questions as for the main site. I understand that one can't deploy a plugin site which has changes in it relating to features not yet released. 3. Plugin SNAPSHOT I would like to deploy a snapshot of the maven-changes-plugin, which is in the sandbox. Am I allowed to do that? If so how do I do it? I'm guessing: mvn deploy:deploy with some setting to direct it to the snapshot repo. If there is an online resource where I can read about all this, then please direct me to it. I looked but couldn't find any... -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: location of maven-changes-plugin?
Ah ok, thank you. (I suppose a snapshot build isn't quite warrented yet? ) On 7/16/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Jesse Kuhnert wrote: > Maybe I am jumping the gun a bit, but is there a known location for the > maven-changes-plugin? I've checked and can't seem to find it on > mojo/snapshots/main dist. > If you want to use the plugin without building it yourself from SVN then you can just use this in your pom: org.codehaus.mojo changes-maven-plugin 2.0-beta-1 ... ... The Changes plugin has not had a release since it moved from mojo to Apache, but I will be pushing for a release real soon. If you want to build it yourself, please do by checking it out from SVN. Temporary instruction (docs for review) can be found here: http://people.apache.org/~dennisl/maven-changes-plugin/source-repository.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
location of maven-changes-plugin?
Maybe I am jumping the gun a bit, but is there a known location for the maven-changes-plugin? I've checked and can't seem to find it on mojo/snapshots/main dist. -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: General issue with clover plugin requiring creative thinking...
If it's a matter of sharing information maybe the ability to store data in a
sort of temporary HashMap sort of session? Ie clover could do something
like:
session.store("CLOVER_INSTRUMENTED_SOURCE_DIR",
"target/src/clover-generated");
And the next guy that needs it could pick it up...Probably not easy to do
though since it's likely that mvn will be invoked multiple times.
On 7/11/06, John Allen <[EMAIL PROTECTED]> wrote:
I have found this aspect of clover a great frustration and would welcome
any
attempt to separate such 'instrument and compile' tasks from the main
project build activities.
John
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: 11 July 2006 06:20
To: Maven Developers List
Subject: Re: General issue with clover plugin requiring creative
thinking...
On 11/07/2006 3:14 PM, Vincent Massol wrote:
> One solution would be to create a profile for the main lifecycle and
another
> one for the clover lifecycle but that's not very handy for end users I
> think. I'll try experimenting with this later on but I think it would
only
> be a hack and not a proper solution. Is there anything better I could
do?
Not that I can think of that doesn't involve core changes (ie, 2.1).
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: [discuss] Java 5
Sounds like a great idea! (not +1'ing since I didn't see an official vote yet) The toolchain stuff will be nice for projects with 1.4 vs 1.5 releases in the mix as well. On 7/7/06, Fabrice Bellingard <[EMAIL PROTECTED]> wrote: On 7/7/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > As far as Maven goes, this would only be the JVM used to run it - it > needs to be able to build projects using any JDK available (and the > support for that needs to first be improved). +1 for Continuum and MRM switching now to Java 5 +1 for Maven 2.1, provided that it is sure that using any JDK is perfectly implemented and usable (Sun is gonna release more often, so this functionality is essential) Fabrice. -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: [RANT] This Maven thing is killing us....
Please, let's not go overboardAnt is nice like c is nice when you need to get small things done. If you have to maintain very large projects with varying releases/users/etc maven is a much better choice. Even with its current flaws. =p On 7/4/06, Steve Loughran <[EMAIL PROTECTED]> wrote: Carlos Sanchez wrote: > The repository is as good as the users/projects make it. There's no > difference at all with using ant and including the wrong jars, maybe > the problem is that how to fix it in maven is not as easy as in ant. > > If project A says it depends on B 1.0 and C says it depends on B 1.1, > there's a conflict in Maven, Ant and anything you want to use, the > difference is that Maven tries to do it for you, but you still can > override that behaviour. > It seems to me that the difference in ant, the duty to set up your classpath belongs to the project alone, so you, the build.xml author are the only one who can make a mess of your CP. However, on any system with transitive dependencies, you are ceding control of your classpath to other programs out there. Even if you think you know exactly what the dependency graph of your app is, an update to a new version of any your dependencies can pull in new metadata, with a new set of dependencies, and potentially a new classpath. This is not a maven-specific problem; anything that supports transitive dependency logic can suffer from it. Gump and Ivy could, though in both cases the descriptors tend to be hand-written tuned to not exhibit the problem. (in gump most projects dont export dependencies, as the default is compile-time-only). > Right now we are in a good position with a huge number of users trying > and testing the metadata in the repository, and forcing projects to > support maven by providing good data. That still assumes that transitive dependencies are a good thing, and that perfect metadata is achievable. I'm not sure about either of those. I also think they're straying dangerously close to one of the big software engineering tar-pits: versioning. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: [RANT] This Maven thing is killing us....
Maybe they've been deploying versions using a normal repository element instead of defining a snapshot repository and -SNAPSHOT version ? On 7/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: YeahEven though in my instance it wasn't what I wanted to happen (not maven's fault, unrelated local patches..), I have seen definite updates of SNAPSHOT builds with the same version. You can pretty easily infer why it works by looking at the timestamp generated poms from them... On 7/2/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > I don't know what you're saying, you are the first one complaining > about it. SNAPSHOTS work for me > > On 7/2/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When > you have a copy of a snapshot versioned artifact, the jar is not updated > when a new jar with same snapshot version is uploaded to the repository. I > already filed this as a bug and hope it will be fixed in 2.0.5. It is > annoying to increase version numbers during development or sending mails > around "please delete xyz in you local repository... > > > > Roger > > > > > -Ursprüngliche Nachricht- > > > Von: Andrew Williams [mailto:[EMAIL PROTECTED] > > > Gesendet: Sonntag, 2. Juli 2006 11:11 > > > An: Maven Developers List > > > Betreff: Re: [RANT] This Maven thing is killing us > > > > > > This is only true for release repositories though, as a > > > snapshot repository will have an updated version when you > > > re-deploy surely? > > > > > > Andy > > > > > > On Sun, 2006-07-02 at 07:01 +0800, Edwin Punzalan wrote: > > > > May I add, that when maven already downloaded a > > > poor/invalid pom, even > > > > after fixing the pom in the repository, maven won't know that it's > > > > > changed (unless the version changed) and it will not > > > download it. So > > > > you end up still using your local repo copy. > > > > > > > > To re-download a pom, you have to delete your local copy first. > > > > > > > > This is a good solution though: > > > > http://jira.codehaus.org/browse/MNG-1258 > > > > > > > > > > > > Mike Perham wrote: > > > > >> -Original Message- > > > > >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > > > >> Sent: Saturday, July 01, 2006 2:59 PM > > > > >> To: Maven Developers List > > > > >> Subject: RE: [RANT] This Maven thing is killing us > > > > >> > > > > >> > > > > >> > > > > >>> Perhaps we can have a rule that every dependency MUST have > > > > >>> > > > > >> a declared > > > > >> > > > > >>> and element so that we know the > > > > >>> > > > > >> developer has thought > > > > >> > > > > >>> about the correct values for them, rather than always using > the > > > > >>> defaults? > > > > >>> > > > > >> That's against Maven philosophy: conventions based builds. > > > > >> Only specify > > > > >> things that don't follow the defaults.. > > > > >> > > > > >> I think the problems with poms are because they're generated by > > > > >> default or converted from maven 1, or just uploaded by > > > someone who > > > > >> wants it there. > > > > >> If a project is built using maven 2, the poms should be > correct. > > > > >> > > > > >> > > > > > > > > > > Agreed, but how do we solve the problem? My suggestion does not > > > > > > force anyone to change their POMs _unless_ they want them > > > hosted at central. > > > > > The issue is that anything hosted at central necessarily > > > becomes a > > > > > publicly available component that others can use. If > > > people want to > > > > > use the conventions, fine, but there obviously needs to > > > be a higher > > > > > standard to make your component publicly available for use by > > > > > others. We are hurting nobody but ourselves by > > > distributing poorly > > > > > defined POMs because inevitably the Maven project as a
Re: [RANT] This Maven thing is killing us....
YeahEven though in my instance it wasn't what I wanted to happen (not maven's fault, unrelated local patches..), I have seen definite updates of SNAPSHOT builds with the same version. You can pretty easily infer why it works by looking at the timestamp generated poms from them... On 7/2/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote: I don't know what you're saying, you are the first one complaining about it. SNAPSHOTS work for me On 7/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When you have a copy of a snapshot versioned artifact, the jar is not updated when a new jar with same snapshot version is uploaded to the repository. I already filed this as a bug and hope it will be fixed in 2.0.5. It is annoying to increase version numbers during development or sending mails around "please delete xyz in you local repository... > > Roger > > > -Ursprüngliche Nachricht- > > Von: Andrew Williams [mailto:[EMAIL PROTECTED] > > Gesendet: Sonntag, 2. Juli 2006 11:11 > > An: Maven Developers List > > Betreff: Re: [RANT] This Maven thing is killing us > > > > This is only true for release repositories though, as a > > snapshot repository will have an updated version when you > > re-deploy surely? > > > > Andy > > > > On Sun, 2006-07-02 at 07:01 +0800, Edwin Punzalan wrote: > > > May I add, that when maven already downloaded a > > poor/invalid pom, even > > > after fixing the pom in the repository, maven won't know that it's > > > changed (unless the version changed) and it will not > > download it. So > > > you end up still using your local repo copy. > > > > > > To re-download a pom, you have to delete your local copy first. > > > > > > This is a good solution though: > > > http://jira.codehaus.org/browse/MNG-1258 > > > > > > > > > Mike Perham wrote: > > > >> -Original Message- > > > >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > > >> Sent: Saturday, July 01, 2006 2:59 PM > > > >> To: Maven Developers List > > > >> Subject: RE: [RANT] This Maven thing is killing us > > > >> > > > >> > > > >> > > > >>> Perhaps we can have a rule that every dependency MUST have > > > >>> > > > >> a declared > > > >> > > > >>> and element so that we know the > > > >>> > > > >> developer has thought > > > >> > > > >>> about the correct values for them, rather than always using the > > > >>> defaults? > > > >>> > > > >> That's against Maven philosophy: conventions based builds. > > > >> Only specify > > > >> things that don't follow the defaults.. > > > >> > > > >> I think the problems with poms are because they're generated by > > > >> default or converted from maven 1, or just uploaded by > > someone who > > > >> wants it there. > > > >> If a project is built using maven 2, the poms should be correct. > > > >> > > > >> > > > > > > > > Agreed, but how do we solve the problem? My suggestion does not > > > > force anyone to change their POMs _unless_ they want them > > hosted at central. > > > > The issue is that anything hosted at central necessarily > > becomes a > > > > publicly available component that others can use. If > > people want to > > > > use the conventions, fine, but there obviously needs to > > be a higher > > > > standard to make your component publicly available for use by > > > > others. We are hurting nobody but ourselves by > > distributing poorly > > > > defined POMs because inevitably the Maven project as a > > whole gets the blame. > > > > > > > > mike > > > > > > > > > > > > > > - 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] > > -- 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] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
surefire/surefire plugin unit tests
I was wondering what the preference would be for where to stick certain tests (specifically for testng || testng running junit tests ) for surefire? I can see that surefire-api has a good start for doing basic junit testing, would that be a good place to place testng tests as well? The patches made so far in http://jira.codehaus.org/browse/MSUREFIRE-134apply to both maven-surefire-plugin as well as surefire-providers/surefire-testng . There are some existing un-used tests sitting over in the maven-surefire-plugin site that I'd like to update and patch in such a way that they are run with normal releases to ensure people notice breaking changes. Most of the changes in the surefire plugin are related to classpath issues, so the ultimate solution may require a mixture of the new plugin testing harness style + just executing a set of known pom configs such as what are in maven-surefire-plugin already. (that is to say, the tests are there but aren't linked to the main pom and so don't get executed unless it's intentional ) Any help at all in a general direction of where to put code so that my patching efforts aren't in vain/not wanted would be greatly appreciated. -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: MSUREFIRE-134
I just wanted to point out that this effectively makes the testng support in surefire "broken" for a good number of users. Anyone hoping to use testng tests with annotations at least... On 6/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: NevermindFixed and attached patch. That wasn't hard at all! (grins imagining 20 other things potentially broken by simple patch ) On 6/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > Hi guys, > > Before I go spinning my wheels in the surefire source too much I was > wondering if anyone here was more familiar than myself with the classloading > semantics involved with the surefire -plugin -> Surefire Booter execution? > > I've made comments on what I've discovered so far but if anyone has any > general guidance suggestions I'd appreciate it. I'm focusing in around the > SurefirePlugin classpath configuration of the booter right now as the source > of the problem but might be way off. Details are explained in the JIRA > issue. > > http://jira.codehaus.org/browse/MSUREFIRE-134 > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: MSUREFIRE-134
NevermindFixed and attached patch. That wasn't hard at all! (grins imagining 20 other things potentially broken by simple patch ) On 6/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: Hi guys, Before I go spinning my wheels in the surefire source too much I was wondering if anyone here was more familiar than myself with the classloading semantics involved with the surefire -plugin -> Surefire Booter execution? I've made comments on what I've discovered so far but if anyone has any general guidance suggestions I'd appreciate it. I'm focusing in around the SurefirePlugin classpath configuration of the booter right now as the source of the problem but might be way off. Details are explained in the JIRA issue. http://jira.codehaus.org/browse/MSUREFIRE-134 -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
MSUREFIRE-134
Hi guys, Before I go spinning my wheels in the surefire source too much I was wondering if anyone here was more familiar than myself with the classloading semantics involved with the surefire -plugin -> Surefire Booter execution? I've made comments on what I've discovered so far but if anyone has any general guidance suggestions I'd appreciate it. I'm focusing in around the SurefirePlugin classpath configuration of the booter right now as the source of the problem but might be way off. Details are explained in the JIRA issue. http://jira.codehaus.org/browse/MSUREFIRE-134 -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: [Result] [vote] [m1] release xdoc-plugin-1.10
+1 on noticing the dtd entry alone. (non binding ) On 6/13/06, Jeff Jensen <[EMAIL PROTECTED]> wrote: I don't have a vote! :-) But it would be +1. Thanks Lukas... -Original Message- From: Lukas Theussl [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 6:13 PM To: Maven Developers List Cc: Maven Project Management Committee List Subject: [Result] [vote] [m1] release xdoc-plugin-1.10 We had a bit of noise on this thread so I hope I quote the result accurately, please correct me if something's wrong. There are 3 binding +1's (Stephane, Arnaud, Lukas) and two people (Jeff Jensen and Dennis Lundberg) who expressed positive opinions, but without casting an explicit vote. I'll do the release ASAP, voting thread is here: http://www.nabble.com/-vote---m1--release-xdoc-plugin-1.10-t1743303.html Cheers, -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: what to do if jar not available on ibiblio?
Ah perfect, thank you Tomasz. On 6/9/06, Tomasz Pik <[EMAIL PROTECTED]> wrote: On 6/9/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > Is there a common pattern people follow when a jar you need isn't available > on ibiblio, but also isn't compatible with the ASF license wise? In > particular I'm finding one project that requires the latest version of > javassist (3.1), which for whatever reason hasn't been published on ibiblio. > > > Can I publish it for them? Heh..Guess not. > http://www.jboss.org/products/list/downloads#javassist Well, it seems that you may use JBoss Maven2 repo directly http://repository.jboss.com/maven2/ > Jesse Kuhnert > Tacos/Tapestry, team member/developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
what to do if jar not available on ibiblio?
Is there a common pattern people follow when a jar you need isn't available on ibiblio, but also isn't compatible with the ASF license wise? In particular I'm finding one project that requires the latest version of javassist (3.1), which for whatever reason hasn't been published on ibiblio. Can I publish it for them? Heh..Guess not. http://www.jboss.org/products/list/downloads#javassist -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
great work!
Just wanted to say that my conversion of a fairly large project (tapestry ) to maven2 has been pretty easy so far.. The only thing that I really had to look hard for was how to create a custom skin, everything else pretty much just worked as expected...So, thanks! :) -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: granting Jesse karma for the repository manager
With a name like Jesse how can you go wrong? ;) +1 (non-binding) On 6/3/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote: On Sat, 3 Jun 2006, Brett Porter wrote: +1 > Hi, > > Jesse M (already a plugins committer), has pinged me off list saying he > has some changes to the repository manager that he'd like to commit. > Rather than going through patches, I'd like to suggest we increase his > karma. We need more people working on it :) > > Cheers, > Brett > > -- > Brett Porter <[EMAIL PROTECTED]> > Apache Maven - http://maven.apache.org/ > Better Builds with Maven - http://library.mergere.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
sync ibiblio
Can anyone help me with this one? http://jira.codehaus.org/browse/MAVENUPLOAD-912 -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: surefire patch needs review
Hmmm...I'm not remembering so well these days either. (I'm also a bit disconnected from what the current surefire code looks like) When I double checked the isTestNGClass logic though it confirmed that the basic function is for it to look for ~any~ annotations on the class in question. (whether qdox or native.) I think I volunteered trying to make it find/run qdox annotations from a 1.5> jre already anyways so I'm probably due for submitting a patch of some sort anyways. On 5/17/06, Brett Porter <[EMAIL PROTECTED]> wrote: Jesse Kuhnert wrote: > P.S. Not using TestNGClassFinder.isTestNGClass is the exact reason > (probably?..) why someone's base class with no test methods and only > @Configuration methods might not be found. Unlikely, as it is going to assume it's a TestNG class as long as it doesn't extend TestCase, right? My understanding was it was using the class, but running 0 tests, though I might be misremembering (I seem to leave my short term memory behind when I travel overseas). - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: surefire patch needs review
P.S. Not using TestNGClassFinder.isTestNGClass is the exact reason
(probably?..) why someone's base class with no test methods and only
@Configuration methods might not be found.
On 5/17/06, Mike Perham <[EMAIL PROTECTED]> wrote:
Sorry, I wasn't trying to denigrate anyone, esp Brett. I think we've
all written dodgy code in our day. I just got a chuckle out of the
particular word choice.
Brett, I'm still getting a 403 Forbidden when I try to check in. Is
there a cron job I need to wait for?
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 17, 2006 1:21 PM
To: Maven Developers List
Subject: Re: surefire patch needs review
To be fair, there was definitely more than a ~little~ bit of pressure
being put on Brett at the time...This might have been something I had in
one of the original patches submitted as well
I don't think extending a junit test necessarily makes it a junit test
though...Let me double check..
Yeah, TestNGClassFinder.isTestNGClass should function properly. (It's
also related to a bug mentioned in the testng users forum. )
Should I try creating a new test case to double check this and submit a
patch with that and any changes related to it or is someone else going
to do it ?
On 5/17/06, Mike Perham <[EMAIL PROTECTED]> wrote:
>
> I presume this is what you are talking about:
>
> // TODO: this is a bit dodgy, but isTestNGClass wasn't working
> if ( "junit.framework.TestCase".equals(
> testSet.getTestClass().getSuperclass().getName() ) )
> {
> xmlTest.setJUnit( true );
> }
>
> Dodgy, indeed. Should it be something like this?
>
> clazz = Class.forName( "junit.framework.Test" ); if (
> testSet.getTestClass().isAssignableFrom( clazz ) ) { ...
> }
>
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 17, 2006 12:32 PM
> To: Maven Developers List
> Subject: Re: surefire patch needs review
>
> It looks fine, but incomplete. I'd forgotten about this better base
> class, and also referenced TestCase in the TestNG provider. If you can
> update that as well, then it should be fine.
>
> I've given you commit rights on surefire.
>
> Cheers,
> Brett
>
> Mike Perham wrote:
> > I have fixed http://jira.codehaus.org/browse/MSUREFIRE-113 but don't
> > have commit privileges. This is a major regression versus 2.1.3 and
> > for those of us who run Junit tests via suites a blocker.
> >
> >
> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For
> > additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> --
> Apache Maven - http://maven.apache.org/ Better Builds with Maven -
> http://library.mergere.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: surefire patch needs review
To be fair, there was definitely more than a ~little~ bit of pressure being
put on Brett at the time...This might have been something I had in one of
the original patches submitted as well
I don't think extending a junit test necessarily makes it a junit test
though...Let me double check..
Yeah, TestNGClassFinder.isTestNGClass should function properly. (It's also
related to a bug mentioned in the testng users forum. )
Should I try creating a new test case to double check this and submit a
patch with that and any changes related to it or is someone else going to do
it ?
On 5/17/06, Mike Perham <[EMAIL PROTECTED]> wrote:
I presume this is what you are talking about:
// TODO: this is a bit dodgy, but isTestNGClass wasn't working
if ( "junit.framework.TestCase".equals(
testSet.getTestClass().getSuperclass().getName() ) )
{
xmlTest.setJUnit( true );
}
Dodgy, indeed. Should it be something like this?
clazz = Class.forName( "junit.framework.Test" );
if ( testSet.getTestClass().isAssignableFrom( clazz ) )
{
...
}
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 17, 2006 12:32 PM
To: Maven Developers List
Subject: Re: surefire patch needs review
It looks fine, but incomplete. I'd forgotten about this better base
class, and also referenced TestCase in the TestNG provider. If you can
update that as well, then it should be fine.
I've given you commit rights on surefire.
Cheers,
Brett
Mike Perham wrote:
> I have fixed http://jira.codehaus.org/browse/MSUREFIRE-113 but don't
> have commit privileges. This is a major regression versus 2.1.3 and
> for those of us who run Junit tests via suites a blocker.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> additional commands, e-mail: [EMAIL PROTECTED]
>
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: javasvn license
Either way if they give you guys trouble you can try sending chuck norris in ;) (sorry, just loved that signature..heh) On 5/16/06, Torsten Curdt <[EMAIL PROTECTED]> wrote: > Where is the license problem? With JavaSVN or SVN? According to > tigris.org, svn is using an apache compatible license. Maybe they are not aware that it is not? Maybe this can be resolved by talking to them ...so they might fix that. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: [vote] release Maven Surefire Plugin 2.2 and Surefire 2.0
Jesse Kuhnert: +1 (non-binding) On 5/2/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: +1 Emmanuel Brett Porter a écrit : > Please test this as much as you can first, given that the classloader > has change somewhat. > > Vote open for 72 hours, based on: > maven-surefire-plugin 2.2-20060501.172356-2 and 2.0-20060501.172351-2 > (r398639) > > [ ] +1 > [ ] +0 > [ ] -1 > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11148&styleName=Html&version=12207 > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&styleName=Html&version=12440 > > > * [MSUREFIRE-23] - Support TestNG > * [MSUREFIRE-57] - Forking documentation improvement to help with > class loader constrainst issues > * [MSUREFIRE-59] - JUnitBattery dies when TestSuite has an anonymous > inner class > * [MSUREFIRE-62] - forkMode=pertest shows Results: line after every > battery, not at the end. > * [MSUREFIRE-63] - Surefire temporary files should be put in target > rather than in the main project directory > * [MSUREFIRE-65] - Surefire causes OOM > * [MSUREFIRE-72] - [surefire-testng] > SurefireReportMojo.executeReport() throws a java.lang.NumberFormatException > * [MSUREFIRE-73] - systemClassLoader.getResource returns null > * [MSUREFIRE-74] - IsolatedClassloader.getResources returns > duplicated results > * [MSUREFIRE-80] - systemProperties and NPE > * [MSUREFIRE-86] - Surefire forking doesn't work on Java 1.3 > * [MSUREFIRE-88] - Surefire fork fails under windows when command > has several quotes > * [MSUREFIRE-93] - maven-surefire-plugin:2.2-SNAPSHOT fails with > invalid option -ea when forking to a JDK < 1.4 > * [MSUREFIRE-94] - settting System property "basedir" is evil. > * [MSUREFIRE-95] - java.lang.NoClassDefFoundError: > org/apache/maven/surefire/util/NestedCheckedException > * [MSUREFIRE-96] - Sometimes xml report has no time atribute in > testcase element > * [MSUREFIRE-56] - The "pertest" option for forking mode should be > renamed more appropriately > * [MSUREFIRE-71] - System properties are not set > * [MSUREFIRE-87] - Improve error stack trace when the error comes > from the user's test code > * [SUREFIRE-25] - surefire property droppings in fork mode > * [SUREFIRE-30] - Wrong classpath separator > * [SUREFIRE-33] - java.lang.ExceptionInInitializerError in TestCase > constructor kills surefire without letting any log > * [SUREFIRE-37] - System properties not working during forking > [surefire-testng branch, patch attached] > * [SUREFIRE-40] - memory leak in junit runner > * [SUREFIRE-35] - refine use of assertion enablement > > Cheers, > Brett > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: [vote] Release surefire plugin 2.1.3 and surefire 1.5.3
+1 (non binding) On 4/1/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > Please vote for these releases that include several bugfixes, mainly > to improve the support of test forking. > > > http://jira.codehaus.org/browse/MSUREFIRE?report=com.atlassian.jira.plugin.system.project:roadmap-panel > > http://jira.codehaus.org/browse/SUREFIRE?report=com.atlassian.jira.plugin.system.project:roadmap-panel > > -- > 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] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
Re: [vote] Release Maven Surefire Report plugin 2.0
Jesse Kuhnert +1 (non-binding) On 3/30/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > Vote open for 72 hours, based on: > maven-surefire-report-plugin 2.0-20060331.032648-2 (r390304) > > [ ] +1 > [ ] +0 > [ ] -1 > > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11222&styleName=Html&version=12481 > > * [MSUREFIREREP-2] - test failures causes report not to be generated > * [MSUREFIREREP-9] - surefire-report-maven-plugin: don't add report for > non java projects > * [MSUREFIREREP-11] - [surefire-report] not contains package name and > testcase details > * [MSUREFIREREP-13] - NPE with svn version of surefire-report-maven-plugin > * [MSUREFIREREP-15] - Add integration logic that allows report to be > created for junit OR testng > * [MSUREFIREREP-17] - Use javascript to show/hide failure details > > Cheers, > Brett > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
Re: surefire branch status?
Probably being paranoid, but is there anything I have left to fix here Brett? I should probably go checkout JIRA to be sure. On 3/17/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > Just as a further note - if anyone is able to test, or help fix the bugs > that have been so far under MSUREFIRE, that'd be a great help. The > codebase should be much less intimidating to those wanting to help out > now... > > Thanks, > Brett > > Brett Porter wrote: > > I got snowed under with various other things. I'll likely look at > > polishing up and doing a beta later in the week. > > > > - Brett > > > > Jesse Kuhnert wrote: > >> Was just wondering if everyone thought this was ready to start > migrating > >> back into trunk? The original post mentioned waiting about a week or so > to > >> do it and it's now been about 2 I think . > >> > >> -- > >> Jesse Kuhnert > >> Tacos/Tapestry, team member/developer > >> > >> Open source based consulting work centered around > >> dojo/tapestry/tacos/hivemind. http://opennotion.com > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
surefire branch status?
Was just wondering if everyone thought this was ready to start migrating back into trunk? The original post mentioned waiting about a week or so to do it and it's now been about 2 I think . -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
Re: Making the current web site suck less
I think what everyone is saying sounds more or less correct, but what is the solution then? If they can't rely on a runtime container to host the site, options become MUCH more limited. Complaints about the UI are fine and I'm sure everyone welcomes them, but possible solutions that fit into the requirements of the projects technical constraints are much more helpful :) I can't think of any really good solutions off the top of my head that don't rely on runtime stuff? On 3/9/06, Brian K. Wallace <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > All in all, I'd have to agree with the sentiments of this. I don't think > anything should be taken personally although I know some personalities > might be inclined to react emotionally at the words used, but if you > look at the sentiment I believe it's right on. Your users may be > developers, but not necessarily for your project. Treat them to a 'user' > site. > > Brian > > Tim O'Brien wrote: > > On 3/8/06, John Casey <[EMAIL PROTECTED]> wrote: > >> > > > > > > > >> Something to think about is maybe not having the initial Maven page be > a > >>> Maven site. ASF sites in general seems to be more Developer focused > >> than > >>> user focused. What if the initial Maven site were more like the front > >> pages > >>> of Mozilla or Rails. An attractive logo, links to resources and > >> materials, > >>> an introduction. The home page should be user focused, Maven > developers > >> are > >>> a minority of the audience here. > >> Are you saying that the developer-centric tendency is appropriate for > >> ASF project web sites, then? I'd tend to say that for a product like > >> Maven (not an API, like commons-cli, for instance) it's worth striving > >> to help the user. Since Maven is an Apache product/project, I'd say > that > >> having a developer site on a different physical location would be > >> bad...they're different aspects of the same product/project. That said, > >> I think we need to section the developer docs off and put them a click > >> or so in from the main landing page...probably with their own landing > >> page. > > > > > > I think I agree with you. > > > > When I said "developer-centric" I meant > > "apache-developer-centric". IMO, more projects need to think about the > user > > who has "30 seconds to figure out the best way to download/use > Derby". The > > current Maven site has too many links, too much distracting people from > what > > should be a simple message - "Download Maven, you won't believe how you > > developed without it. We promise.".I'm not saying that we should > all > > become marketing people, but it's something to consider. > > > > > >> It's not a simple hierarchy, but then, we have a great deal of > variation > >> among our audience members. As these audience members [possibly] > >> transition from users to contributors and so on, we don't want a > >> separation like this to get in their way...there should be *some* > >> cohesiveness, I would think... > > > > > > I'm not saying this to be contrary, bear with me: most people that use > > Maven don't care to know much about the internals or how it is being > > developed. They simply want to download a product that works, is > > well documented, and use it. A small minority of those users will get > an > > itch that needs to be scratched or decide that the gift of free software > > should be repaid by involvement in a community. So, if you wrote up a > > survey, and quizzed people who use Maven every day, I think you'd > probably > > find that most of them think Jason van Zyl is a famous magician and the > > Meritocracy is a spell in Dungeons and Dragons. I'm not saying this as > a > > cynical jibe, but to make the point that regardless of the Maven > website, we > > will always about an equal mix - out of 100 - 95 people download Maven, > 5 > > subscribe to the users list for a week, maybe 4 ask questions on the > user > > list, and, if you are lucky, 1 submits a patch. And even that's > > overestimating, apply that forumla to the httpd project and it would > have > > 10^5 patches submitted per year. > > > > Turn your statement around. "audience members [possibly] transition > > form users to contributors". Assume that a simpler user focused launch > > page made it easier for people to adopt Maven. If this "separation" of > > user-focused and developer-focused documentation increases the > population of > > users, we've increase the pool of potential contributors. I'm betting > on > > the fact that as users "root around" the documentation, they'll catch on > to > > the fact that this is the ASF they will pick up the community. > > > > I think a good strategy is to make the landing page for Maven as simple > as > > possible, with a good short sell, as little text as possible, link to > > download, and some news and announcements. The Maven launch page should > be > > very similar to the Mozilla launch page - there
Re: [vote] replace surefire and surefire plugin trunk with test NG branches
For my purposes everything is now working great. (Assuming new patch/equivalent is applied and testng dependency is upgraded to 4.7 ) On 3/4/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > +1 (non-binding). I'm going to start testing things right now and will > jira back on any issues found. > > > On 3/4/06, Brian E. Fox < [EMAIL PROTECTED]> wrote: > > > > I would like at least a week to try this out as we are using testNG via > > ant currently. I'll be away Mon&Tue but can test later on and report my > > experience. > > > > -Original Message- > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > Sent: Saturday, March 04, 2006 8:09 AM > > To: Maven Developers List > > Subject: Re: [vote] replace surefire and surefire plugin trunk with test > > NG branches > > > > Brett Porter wrote: > > > Hi, > > > > > > I've been doing the revolutionary thing with surefire. The branch is > > > now working for pojo, junit and testNG tests, under all 3 fork modes. > > > > > Some other bugs have been fixed, the surefire and junit classloaders > > > are separate to avoid plexus-utils and junit version clashes (this > > > doesn't happen for test ng yet), and the test suite runners are now in > > > > > the provider structure so you don't have to use testng if you don't > > > want (or even junit if you want to run pojo tests using the assert > > keyword). > > > > > > The code has been heavily refactored, so I'd like folks to review and > > > test it and vote on whether it should replace the previous trunk. I > > > think its a lot more readable now, but that might just be me :) If > > > something you think is required is missing, or something in the new > > > design doesn't seem right, now is the best time to address it. > > > > Looks good to me and if the Maven bootstrap works and activemq-core then > > > > I think things should be fine. What do you think the best approach is > > for introducing the new code into the wild? > > > > 1) Let people test the new snapshot for a while and if nothing crops up > > release it? > > 2) Do a quick release of what's in trunk + 1) > > 3) Possibly bump the major number of the surefire plugin to match the > > bump in surefire on the trunk? > > > > I would suggest having a period of a week to let people try it and if > > nothing is reported then perform the swap. > > > > > [ ] +1 > > > [ ] 0 > > > [ ] -1 > > > > > >>From me, +1. > > > > > > Cheers, > > > Brett > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] For > > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > > commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
[jira] Commented: (MSUREFIRE-69) stop output to test-output directory
[ http://jira.codehaus.org/browse/MSUREFIRE-69?page=comments#action_60176 ] Jesse Kuhnert commented on MSUREFIRE-69: Awesome, thanks Brett! I don't use a sun jvm so don't have the javadoc libs available via normal means. (ibm's jre runs much much faster on linux than sun) It looks like it runs though so I've added it to cvs . > stop output to test-output directory > > > Key: MSUREFIRE-69 > URL: http://jira.codehaus.org/browse/MSUREFIRE-69 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Reporter: Brett Porter > Fix For: 2.2 > Attachments: pom.xml, surefire-patch.txt, surefire-patch.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-69) stop output to test-output directory
[ http://jira.codehaus.org/browse/MSUREFIRE-69?page=comments#action_60167 ] Jesse Kuhnert commented on MSUREFIRE-69: I think it will ~probably~ be possible to build it with m2? There have to be other projects with seperate source trees for differing jre versions. I don't know how they handle it but any amount of research I've done so far hasn't made it seem very easy. > stop output to test-output directory > > > Key: MSUREFIRE-69 > URL: http://jira.codehaus.org/browse/MSUREFIRE-69 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Reporter: Brett Porter > Fix For: 2.2 > Attachments: surefire-patch.txt, surefire-patch.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-69) stop output to test-output directory
[ http://jira.codehaus.org/browse/MSUREFIRE-69?page=all ] Jesse Kuhnert updated MSUREFIRE-69: --- Attachment: surefire-patch.txt > stop output to test-output directory > > > Key: MSUREFIRE-69 > URL: http://jira.codehaus.org/browse/MSUREFIRE-69 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Reporter: Brett Porter > Fix For: 2.2 > Attachments: surefire-patch.txt, surefire-patch.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-69) stop output to test-output directory
[ http://jira.codehaus.org/browse/MSUREFIRE-69?page=comments#action_60152 ] Jesse Kuhnert commented on MSUREFIRE-69: Got it now. Didn't realize TestNG was instantiated in two different places. The patch supplied only works against the latest testng, which currently only lives in testng cvs head . (4.7) No output files/directories are created now. Still need to look at other jira issues created, create a new ibiblio upload. (Is it really even possible to create a pom capable of building testng properly? I'm starting to think it isn't. I had to manually copy over my testng jars to get them installed correctly because the classsifier parm was being ignored) > stop output to test-output directory > > > Key: MSUREFIRE-69 > URL: http://jira.codehaus.org/browse/MSUREFIRE-69 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Reporter: Brett Porter > Fix For: 2.2 > Attachments: surefire-patch.txt, surefire-patch.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-69) stop output to test-output directory
[ http://jira.codehaus.org/browse/MSUREFIRE-69?page=comments#action_60116 ] Jesse Kuhnert commented on MSUREFIRE-69: No I think you're right, I just think it's something I'm not completely in control of. TestNG tries very hard to provide defaults that do have outputs. The new constructor seemed to be the only option without wildly changing other things internal to testng. I've made it so that setUseDefaultReports ( false ) works for the most part, but am not completely sure that html output won't still be generated with this alone. Perhaps me figuring out how to make my local repo use my surefire code changes will solve my dilemna. I wasn't having any problems getting the surefire stuff to use the new testng code, it was problems getting the new surefire code to be used by testing in general. > stop output to test-output directory > > > Key: MSUREFIRE-69 > URL: http://jira.codehaus.org/browse/MSUREFIRE-69 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Reporter: Brett Porter > Fix For: 2.2 > Attachments: surefire-patch.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-69) stop output to test-output directory
[ http://jira.codehaus.org/browse/MSUREFIRE-69?page=comments#action_60113 ] Jesse Kuhnert commented on MSUREFIRE-69: Hi Brett, The use of that method is decieving in it's current form. The default no args constructor creates a default listener for html reporting output. After that, setting the defaultListeners boolean flag is problematic because you have no idea what in the local list are defaults and what are things people have added. I would like to take out the setter altogether but haven't as I'm not sure if it's used by others. The new constructor with a boolean arg should fix our problems. I also re-factored the suiterunner to not add a bunch of others by default (ie the xml/txt outputs, which are our biggest problem). So, this should be fixed by using testng from the latest cvs head. I've tried testing it locally but for some reason doing a mvn install of surefire isn't causing my local repo jars to be used. It could be that the surefire plugin is explicitly using a particular version of surefire that takes precedence over my local build? > stop output to test-output directory > > > Key: MSUREFIRE-69 > URL: http://jira.codehaus.org/browse/MSUREFIRE-69 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Reporter: Brett Porter > Fix For: 2.2 > Attachments: surefire-patch.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-69) stop output to test-output directory
[ http://jira.codehaus.org/browse/MSUREFIRE-69?page=all ] Jesse Kuhnert updated MSUREFIRE-69: --- Attachment: surefire-patch.txt > stop output to test-output directory > > > Key: MSUREFIRE-69 > URL: http://jira.codehaus.org/browse/MSUREFIRE-69 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Reporter: Brett Porter > Fix For: 2.2 > Attachments: surefire-patch.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-69) stop output to test-output directory
[ http://jira.codehaus.org/browse/MSUREFIRE-69?page=comments#action_60064 ] Jesse Kuhnert commented on MSUREFIRE-69: I meant fixed in testng itself, it probably got re-enabled somehow. Will report back when testng get's fixed and if any patches need to be made in surefire to call new methods. > stop output to test-output directory > > > Key: MSUREFIRE-69 > URL: http://jira.codehaus.org/browse/MSUREFIRE-69 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Reporter: Brett Porter > Fix For: 2.2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-69) stop output to test-output directory
[ http://jira.codehaus.org/browse/MSUREFIRE-69?page=comments#action_60059 ] Jesse Kuhnert commented on MSUREFIRE-69: I had originally removed this when developing the first round of patches but it seems to have re-surfaced again. Will do it again and sync up to make sure it doesn't re-appear. > stop output to test-output directory > > > Key: MSUREFIRE-69 > URL: http://jira.codehaus.org/browse/MSUREFIRE-69 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Reporter: Brett Porter > Fix For: 2.2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] replace surefire and surefire plugin trunk with test NG branches
+1 (non-binding). I'm going to start testing things right now and will jira back on any issues found. On 3/4/06, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > I would like at least a week to try this out as we are using testNG via > ant currently. I'll be away Mon&Tue but can test later on and report my > experience. > > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 04, 2006 8:09 AM > To: Maven Developers List > Subject: Re: [vote] replace surefire and surefire plugin trunk with test > NG branches > > Brett Porter wrote: > > Hi, > > > > I've been doing the revolutionary thing with surefire. The branch is > > now working for pojo, junit and testNG tests, under all 3 fork modes. > > > Some other bugs have been fixed, the surefire and junit classloaders > > are separate to avoid plexus-utils and junit version clashes (this > > doesn't happen for test ng yet), and the test suite runners are now in > > > the provider structure so you don't have to use testng if you don't > > want (or even junit if you want to run pojo tests using the assert > keyword). > > > > The code has been heavily refactored, so I'd like folks to review and > > test it and vote on whether it should replace the previous trunk. I > > think its a lot more readable now, but that might just be me :) If > > something you think is required is missing, or something in the new > > design doesn't seem right, now is the best time to address it. > > Looks good to me and if the Maven bootstrap works and activemq-core then > I think things should be fine. What do you think the best approach is > for introducing the new code into the wild? > > 1) Let people test the new snapshot for a while and if nothing crops up > release it? > 2) Do a quick release of what's in trunk + 1) > 3) Possibly bump the major number of the surefire plugin to match the > bump in surefire on the trunk? > > I would suggest having a period of a week to let people try it and if > nothing is reported then perform the swap. > > > [ ] +1 > > [ ] 0 > > [ ] -1 > > > >>From me, +1. > > > > Cheers, > > Brett > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [vote] separate mailings lists for humans/JIRA/CI/commits
+1 (non-binding) On 3/2/06, Yann Le Du <[EMAIL PROTECTED]> wrote: > > +1 > > - Yann > > > 2006/3/1, Jason van Zyl <[EMAIL PROTECTED]>: > > > > Hi, > > > > > > > > I just wanted to close this up as I think it's a good idea and > > anything > > > > that let's people manage their mail better IMO is a good thing. > > > > > > > > +1 > > > > > > > > In this type of vote it is non-technical so simple majority wins, > but > > if > > > > it's close we can continue the discussion but I think a majority > > wanted > > > > preferred the separation. > > > >
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_59000 ] Jesse Kuhnert commented on MSUREFIRE-23: The testng community is feeling very sad from not having maven 2. :'( > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Fix For: 2.2 > Attachments: maven-patches.tgz, maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, > surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating mock objects for core components
Wherever you decide to put it I think it's a great idea. Found myself in certain unit test situations where this would've been very helpful. j On 2/10/06, Allison, Bob <[EMAIL PROTECTED]> wrote: > > Now that I think about it, though, for 2.1 would there be a way to > package the entire set of compile phases (generate-xx-sources, > process-xx-sources, generate-xx-resources, process-xx-resources, > compile-xx, process-xx-classes, package-xx) in something that would > allow a project or plugin to define a complete, independent compile > sequence for whatever files they need? I'm thinking along the lines of > the clean plugin's lifecycle. If you had a "ubercompiler" plugin which > had its own lifecycle, then it would be fairly easy to use it for a test > compile lifecycle and a mock-object lifecycle and anything else people > need. > > -Original Message- > From: Allison, Bob [mailto:[EMAIL PROTECTED] > Sent: Friday, February 10, 2006 06:12 > To: Maven Developers List > Subject: RE: Creating mock objects for core components > > > My personal preference would be src/mock/... structured like > src/test/... and be able to build an output artifact jar with classifier > "mock" as part of the normal build. To do this, unfortunately, requires > resolution of MCOMPILER-13. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos > Sanchez > Sent: Thursday, February 09, 2006 17:06 > To: Maven Developers List > Subject: Creating mock objects for core components > > > Hi, > > I think it'd be useful to create a project with mock objects, eg > Artifact, MavenProject,... as I have already seen some implementations > in plugins test (eg. jar plugin), to avoid repetition and make it easy > to test stuff. it doesn't mean start making mocks right now, but > setting up a place where to put the stuff as we make it. > > What's the suggested approach? > > a) create a new project with only mocks for each project already > existing > - maven-model-mock > - maven-artifact-mock > pros: clean api > cons: many new projects > > b) put the mocks in the test folder and deploy the test jars > pros: no new projects, mocks are close to implementations, same > lifecycle > cons: dirty api, tests also included in jar, we should follow > backwards compatibility in tests, no way to say what is supposed to be > used and what not > > c) create a new folder src/mock/main (and src/mock/test if we really > need it) > pros: both of the other two > cons: change directory structure now ? > > WDYT? > > - > 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] > >
[jira] Commented: (MAVENUPLOAD-695) Publish new testng release files to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-695?page=comments#action_57494 ] Jesse Kuhnert commented on MAVENUPLOAD-695: --- Oh wow, I hadn't realised that you had already updated it as well. I don't have all of the maven patches sitting on my computer at home so I'll be able to play with everything again tomorrow morning. (est) Thanks a ton for all the insightful help! > Publish new testng release files to ibiblio > --- > > Key: MAVENUPLOAD-695 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-695 > Project: maven-upload-requests > Type: Task > Reporter: Jesse Kuhnert > Assignee: Carlos Sanchez > Attachments: testng-4.4.7-jdk14-bundle.jar, testng-4.4.7-jdk15-bundle.jar > > > This is a new ibiblio addition. The bundle jars aren't actually available on > a normal public facing website (yet), but are attached to the issue > referenced in the bundle url. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-695) Publish new testng release files to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-695?page=all ] Jesse Kuhnert closed MAVENUPLOAD-695: - Resolution: Fixed > Publish new testng release files to ibiblio > --- > > Key: MAVENUPLOAD-695 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-695 > Project: maven-upload-requests > Type: Task > Reporter: Jesse Kuhnert > Assignee: Carlos Sanchez > Attachments: testng-4.4.7-jdk14-bundle.jar, testng-4.4.7-jdk15-bundle.jar > > > This is a new ibiblio addition. The bundle jars aren't actually available on > a normal public facing website (yet), but are attached to the issue > referenced in the bundle url. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-695) Publish new testng release files to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-695?page=comments#action_57442 ] Jesse Kuhnert commented on MAVENUPLOAD-695: --- I'd like to pretend that I understand what you just said but I don't ;) The modified surefire patches I submitted in the other jira issue already handle including the right version of testng based on the running jvm. I've tested this on my local box with seperate maven project builds and everything seems to work fine as long as the user at least specifies one of the artifcat id's as a depedency (ie testng-14 or testng-1.5). I'm unsure what this one pom should look like. Does using profiles mean that all people using maven with testng will need to configure an additional profile config to be able to use it? Sorry for all the questions. I've browsed the maven docs as best I could (including the plugin dev guide), but am having trouble with this last step. All of the testing I did with these jars and the ticket linked to this one was based off of installing these two jars with commands like this: mvn install:install-file -DartifactId=testng-jdk15 -DgroupId=org.testng -Dversion=4.4.7 -Dpackaging=jar -Dfile=testng-4.4.7-jdk15.jar mvn install:install-file -DartifactId=testng-jdk14 -DgroupId=org.testng -Dversion=4.4.7 -Dpackaging=jar -Dfile=testng-4.4.7-jdk14.jar I started creating a parent->module heirarchy but started getting frustrated when I realised I needed to share classes in both jars..Not your problem to be sure, I think I just need a little more nudging. (Is there any other project's pom I can look at doing something similar? ) > Publish new testng release files to ibiblio > --- > > Key: MAVENUPLOAD-695 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-695 > Project: maven-upload-requests > Type: Task > Reporter: Jesse Kuhnert > Assignee: Carlos Sanchez > Attachments: testng-4.4.7-jdk14-bundle.jar, testng-4.4.7-jdk15-bundle.jar > > > This is a new ibiblio addition. The bundle jars aren't actually available on > a normal public facing website (yet), but are attached to the issue > referenced in the bundle url. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_57300 ] Jesse Kuhnert commented on MSUREFIRE-23: Sorry about the bad ibiblio upload again, don't know how I managed to do that but I re-opened the upload request with what I believe was the intended ibiblio files attached directly. As for the documentation, I have added a small amount to testng's docs directly as well, but it would be nice to have the core maven xdoc/apt documentation updated :) > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-patches.tgz, maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, > surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MAVENUPLOAD-695) Publish new testng release files to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-695?page=all ] Jesse Kuhnert reopened MAVENUPLOAD-695: --- Sorry for the bad first attempt, I'm going to try attaching the bundled pom-friendly jars directly to the ticket this time. > Publish new testng release files to ibiblio > --- > > Key: MAVENUPLOAD-695 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-695 > Project: maven-upload-requests > Type: Task > Reporter: Jesse Kuhnert > Assignee: Carlos Sanchez > Attachments: testng-4.4.7-jdk14-bundle.jar, testng-4.4.7-jdk15-bundle.jar > > > This is a new ibiblio addition. The bundle jars aren't actually available on > a normal public facing website (yet), but are attached to the issue > referenced in the bundle url. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-695) Publish new testng release files to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-695?page=all ] Jesse Kuhnert updated MAVENUPLOAD-695: -- Attachment: testng-4.4.7-jdk15-bundle.jar testng-4.4.7-jdk14-bundle.jar > Publish new testng release files to ibiblio > --- > > Key: MAVENUPLOAD-695 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-695 > Project: maven-upload-requests > Type: Task > Reporter: Jesse Kuhnert > Assignee: Carlos Sanchez > Attachments: testng-4.4.7-jdk14-bundle.jar, testng-4.4.7-jdk15-bundle.jar > > > This is a new ibiblio addition. The bundle jars aren't actually available on > a normal public facing website (yet), but are attached to the issue > referenced in the bundle url. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_57185 ] Jesse Kuhnert commented on MSUREFIRE-23: Hmmm Well yes, that is how I thought I had packaged them. I must have done somthing wrong with my mvn-upload request. This doesn't look right at all. I will post a new mvn-upload ticket today in hopes of resolving this. > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-patches.tgz, maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, > surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-695) Publish new testng release files to ibiblio
Publish new testng release files to ibiblio --- Key: MAVENUPLOAD-695 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-695 Project: maven-upload-requests Type: Task Reporter: Jesse Kuhnert This is a new ibiblio addition. The bundle jars aren't actually available on a normal public facing website (yet), but are attached to the issue referenced in the bundle url. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Jesse Kuhnert updated MSUREFIRE-23: --- Attachment: maven-patches.tgz > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-patches.tgz, maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, > surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_56545 ] Jesse Kuhnert commented on MSUREFIRE-23: Arghh! I've been trying to create patches for the last half hour but think I've screwed some state up with subversion somehow. I have a new src/it/test3 directory that subversion says is already under version control, and yet it won't let me add it to the patch because of an error stating: "diff --old /home/jkuhnert/projects/maven-surefire-plugin Working copy not locked; this is probably a bug, please report svn: Working copy '/home/jkuhnert/projects/maven-surefire-plugin/src/it/test3' is missing or not locked" I've tried all the svn commands I could think of to fix it but am running out of ideas. > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, > surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_56530 ] Jesse Kuhnert commented on MSUREFIRE-23: I have no idea hot to manage all of these patches. I'm not quite as used to patching as committing, hence all of my original mistakes. wtf do I do to differntiate them? No need for thanks, ultimately I am helping myself. Nothing would be worse than the total runtime of junit v s testng tests to suffer throughn again. Everything is completely finished "for real" this time, I just got called for dinner and such before I had time to generate a new set of patch files. I will upload them tomorrow when I make more sense again. > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, > surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSUREFIRE-46) Ensure java 1.4 compatibility
[ http://jira.codehaus.org/browse/MSUREFIRE-46?page=all ] Jesse Kuhnert closed MSUREFIRE-46: -- Resolution: Fixed Made changes necessary to set the test source directory so the annotationfinder can locate javadoc annotations. > Ensure java 1.4 compatibility > - > > Key: MSUREFIRE-46 > URL: http://jira.codehaus.org/browse/MSUREFIRE-46 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Environment: java <= 1.4 > Reporter: Jesse Kuhnert > > > The javadoc annotation finder works a little bit differently than the 1.5 > annotation finder, ensure that when running in a 1.4jvm people can run and > correctly see test results. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSUREFIRE-40) Add relevant parameters for configuring testng
[ http://jira.codehaus.org/browse/MSUREFIRE-40?page=all ] Jesse Kuhnert closed MSUREFIRE-40: -- Resolution: Fixed Have added all relevant parameters and provided test cases asserting they work. The new pom xml configurable parameters are: * groups - groups to run test in * excludeGroups - groups to specifically include from run * suiteXmlFiles - List of optional testng suite xml definitions to run * threadCount - Number of threads to run for tests * parallel - When using threads, whether or not to run them in parallel > Add relevant parameters for configuring testng > -- > > Key: MSUREFIRE-40 > URL: http://jira.codehaus.org/browse/MSUREFIRE-40 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Environment: any > Reporter: Jesse Kuhnert > > > Add all of the normal testng parameters to runtime, like which groups to run, > an optional suite.xml file to use, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSUREFIRE-48) Enable assertions for underlying jvm
Enable assertions for underlying jvm Key: MSUREFIRE-48 URL: http://jira.codehaus.org/browse/MSUREFIRE-48 Project: Maven 2.x Surefire Plugin Type: Sub-task Environment: jre 1.5 > Reporter: Jesse Kuhnert Some jre's don't have assertions enabled by default and require a runtime parameter of "-ea" in order to use them. Since TestNG supports assertions and it would be nice to use the short hand method occassionally, determine feasability of either enabling them in the currently running jvm, or adding the command line params to the bootloader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSUREFIRE-46) Ensure java 1.4 compatibility
Ensure java 1.4 compatibility - Key: MSUREFIRE-46 URL: http://jira.codehaus.org/browse/MSUREFIRE-46 Project: Maven 2.x Surefire Plugin Type: Sub-task Environment: java <= 1.4 Reporter: Jesse Kuhnert The javadoc annotation finder works a little bit differently than the 1.5 annotation finder, ensure that when running in a 1.4jvm people can run and correctly see test results. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSUREFIRE-47) Add Distributed testing ability
Add Distributed testing ability --- Key: MSUREFIRE-47 URL: http://jira.codehaus.org/browse/MSUREFIRE-47 Project: Maven 2.x Surefire Plugin Type: Sub-task Environment: any Reporter: Jesse Kuhnert Priority: Minor TestNG now supports running distributed tests, determine feasability of integrating this into surefire. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_56380 ] Jesse Kuhnert commented on MSUREFIRE-23: Thank you for being so patient and diligent Gunnar. I think the missing unit test was another brain fart of mine when using the subclipse eclipse plugin. I've since fixed that but wanted to go ahead and finish off the rest of the parameters and such before I upload another set of patches. Should be soon. > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, > surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_56119 ] Jesse Kuhnert commented on MSUREFIRE-23: Hi Guys, Just wondering how I should proceed here. I've still got a few pieces to the plugin to complete, but am hesitant to keep writing code if this patch doesn't feel right to everyone. I don't remember how the rules for ASF committer access work on a per-project basis, but if it helps I'm already part of the ASF. Perhaps a temporary, or surefire-only committer access might make this easier for everyone? I know people are busy and such. Just a thought :) > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, > surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-40) Add relevant parameters for configuring testng
[ http://jira.codehaus.org/browse/MSUREFIRE-40?page=comments#action_56006 ]
Jesse Kuhnert commented on MSUREFIRE-40:
I accidently addressed this in the top level issue comments, but my first
thoughts were that it should probably be ok to add specific testing framework
configurations with the following in mind:
-) Includes/Excludes still overlap - I'm still able to hand off an array of
class names to run to testng, so this very basic configuration point that the
current documentation covers would still hold true, an important factor I think
in getting people up and running with as little hassle as possible.
The other, more specific testng configuration specs should still be very light
in configuration as they mostly do all the same things.
-) Grouping - TestNG lets you group your tests/methods/etc via javadoc or real
annotation grouping semantics, so a sample configuration point for this might
look as simple as:
function
integration
-) Suites - For those people that use the xml suite run configuration, it
would be a normal-ish file path config:
${basedir}/src/test/test-data/testng-suite.xml
There are probably a couple other parameters that I'm leaving out but I don't
think any of them require more than a line or two max to configure properly.
> Add relevant parameters for configuring testng
> --
>
> Key: MSUREFIRE-40
> URL: http://jira.codehaus.org/browse/MSUREFIRE-40
> Project: Maven 2.x Surefire Plugin
> Type: Sub-task
> Environment: any
> Reporter: Jesse Kuhnert
>
>
> Add all of the normal testng parameters to runtime, like which groups to run,
> an optional suite.xml file to use, etc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_56005 ] Jesse Kuhnert commented on MSUREFIRE-23: Gunnar, In regard to the 3 vs 2 suite assertion, it really should be 3 suites found. It could be an indicator that the testng reports aren't running correctly if only 2 exist. What is your environment like? I'm running jre 1.5 as the default jvm with "-ea" specified in MAVEN_OPTS to enable assertions. For the configuration semantics, like running a single test vs running this or that, I'm not sure how far this should be attempted to be taken. JUnit and TestNG are so very different when it comes to this. I've successfully gotten the includes/excludes working just fine but this doesn't enable all of the features in testng that I would personally like to use. Such as configuring "groups" to run at runtime, or using the thread specifiers, or running distributed tests, etc. ... Is it really a horrible thing if we allow the specific configurations for testng or junit that don't necessarily overlap? I don't know. My gut tells me that this doesn't seem entirely bad, and I'm not seeing a lot of situations where people are thrown off because presumably they are very familiar with the testing framework of their choice, and at least enough of the configuration parameters overlap to get them started. > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, > surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Jesse Kuhnert updated MSUREFIRE-23: --- Attachment: surefire-report-maven-plugin-patch.txt surefire-patch.txt > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, > surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Jesse Kuhnert updated MSUREFIRE-23: --- Attachment: surefire-patch.txt > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Jesse Kuhnert updated MSUREFIRE-23: --- Attachment: surefire-patch.txt > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_55656 ] Jesse Kuhnert commented on MSUREFIRE-23: The testng jars unfortunately don't live in ibiblio right now (will start happening once these patches get resolved), but the commands I've been using to install it into the local maven repo are: mvn install:install-file -DartifactId=testng-jdk15 -DgroupId=testng -Dversion=4.4.5 -Dpackaging=jar -Dfile=testng-4.4.5-jdk15.jar mvn install:install-file -DartifactId=testng-jdk14 -DgroupId=testng -Dversion=4.4.5 -Dpackaging=jar -Dfile=testng-4.4.5-jdk14.jar IMPORTANT!!! I had to modify my MAVEN_OPTS environment variable in order to get my jvm to read annotations by default. I don't know if there is a better workaround for this currently, I hope so as that would be a huge annoyance for users. I don't mind tackling that part as well, one thing at a time... My MAVEN_OPTS looks like: export MAVEN_OPTS="-ea" > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSUREFIRE-41) Enable show/hide on surefire report
[ http://jira.codehaus.org/browse/MSUREFIRE-41?page=all ] Jesse Kuhnert closed MSUREFIRE-41: -- Resolution: Duplicate Moving it over to mojo > Enable show/hide on surefire report > --- > > Key: MSUREFIRE-41 > URL: http://jira.codehaus.org/browse/MSUREFIRE-41 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Environment: any > Reporter: Jesse Kuhnert > > > enable show/hide on surefire report -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_55535 ] Jesse Kuhnert commented on MSUREFIRE-23: I still need to convert testng to use maven, at least for publishing to testng but thought I'd save myself the trouble if everyone hates the patches. > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSUREFIRE-41) Enable show/hide on surefire report
Enable show/hide on surefire report --- Key: MSUREFIRE-41 URL: http://jira.codehaus.org/browse/MSUREFIRE-41 Project: Maven 2.x Surefire Plugin Type: Sub-task Environment: any Reporter: Jesse Kuhnert enable show/hide on surefire report -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSUREFIRE-40) Add relevant parameters for configuring testng
Add relevant parameters for configuring testng -- Key: MSUREFIRE-40 URL: http://jira.codehaus.org/browse/MSUREFIRE-40 Project: Maven 2.x Surefire Plugin Type: Sub-task Environment: any Reporter: Jesse Kuhnert Add all of the normal testng parameters to runtime, like which groups to run, an optional suite.xml file to use, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_55533 ] Jesse Kuhnert commented on MSUREFIRE-23: These patches should be enough for someone to play around with the patch work. I'm going to create sub-tasks on this issue for the work I still have left to do. > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Jesse Kuhnert updated MSUREFIRE-23: --- Attachment: surefire-patch.txt maven-surefire-report-maven-plugin-patch.txt maven-surefire-plugin-patch.txt > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Jesse Kuhnert updated MSUREFIRE-23: --- Attachment: testng-4.4.5-jdk15.jar > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Jesse Kuhnert updated MSUREFIRE-23: --- Attachment: testng-4.4.5-jdk14.jar > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Attachments: maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_55510 ] Jesse Kuhnert commented on MSUREFIRE-23: Ahh, I didn't know about this part. The runtime errors are the biggest reason I did it, but perhaps there is an easy solution to the other dependencies. I have no idea. I sent the testng group my patch a few minutes ago, when I get some approval (or make modifications + approval to get it into a commitable state) I'll post the patches here for all the surefire bits along with the jars you'll need on ibiblio to make it work. I'll submit the report plugin patch to the othe jira ticket and link these two tickets together. (If that's possible from completely different jira's. ) > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_55488 ] Jesse Kuhnert commented on MSUREFIRE-23: The reason why the reporting plugin needed work was because he really needed a better grouping construct. Class names and package names were being parsed out of attributes in a very unintuitive way, but I've already made all the code changes to the report plugin as well, just one tiny little javascript change to the output and I'll be done. Either way I'll post all of my patches to everyone tomorrow morning (e.s.t.) It was currently doing things like this in the xml output that was causing string index errors(while looking for class keyword): Which I've changed to something more universally doable in junit & testng: I think the change was needed whether testng came into the picture or not, but if people don't like it there may be other options, I was just getting runtime errors or else I might've tried to avoid doing anything at all. > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_55228 ] Jesse Kuhnert commented on MSUREFIRE-23: Hey Brett, do you have any issues with me changing this so that reports are generated even with test failures? All of my experience with these things so far seems to indicate that ~not~ generating a report should be the exception to the rule that requires additional properties to be set, but that always generating reports would definitely be the desired behaviour for the majority of people. I'm going to add this in while I'm at it, unless someone says otherwise. > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: mike perham > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSUREFIRE-39) Add integration logic that allows report to be created for junit OR testng
Add integration logic that allows report to be created for junit OR testng -- Key: MSUREFIRE-39 URL: http://jira.codehaus.org/browse/MSUREFIRE-39 Project: Maven 2.x Surefire Plugin Type: Improvement Environment: any Reporter: Jesse Kuhnert I'm currently in the middle of patching/working with testng and the maven-surefire plugin core parts to provide a seamless testng integration point and am on the final task of getting the report to be a little friendlier. This is the jira issue for the surefire portion: http://jira.codehaus.org/browse/MSUREFIRE-23 I think at the very least I wanted to change the runtime to ~not~ try and parse class/package constructs out of the test name attributes, but work in an agnostic manner to just group things as they appear in the xml output. I also intend to embed a very minimal amount of javascript into the generated html page so that report errors/stack traces can have hide/show buttons enabling the detailed viewing of their contents. Does this sound reasonable to everyone? I've got the source checked out right now and will be working on this today. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_55174 ] Jesse Kuhnert commented on MSUREFIRE-23: I think that the majority of work is done now, besides a lot of weird reporting behaviour. Such as lots of assumptions about the xml output format, I mean it's getting substring index errors because it's hidden a sub "meta format" of "class " into the suite name attribute. G :/ Does this mean I need to submit a patch to codehaus as well? I think that will be 4 different project patches total to somehow get done all at once, what do I even do to get everyone on my version so they can test my results? I was thinking about trying to get testng to commit my changes and release to ibiblio first and then submit them all here afterwards. .. > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: mike perham > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_55133 ] Jesse Kuhnert commented on MSUREFIRE-23: After some discussions on the testng list it looks like the easiest solution may be to use the already existing classloader include logic in the booter, which I have done, to optionally include the right version of testng to include depending on the running jvm version. This has worked so far. I'll update the issue more when I get closer to a final patch-worthy solution. (Should be early next week, I have to sync up with testng to get them patched and uploaded onto ibiblio as well). > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: mike perham > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
