RE: Publishing to Maven Central
It looks like you have specified all of the dependencies in the ApacheJMeter_parent pom. I thought you wanted a unified set of dependencies that are only declared in one place. The code I have right now will deploy to a repo using ant to call the mvn deploy command via an exec command. It's working on Linux and Windows and just requires you to have maven installed upon your system. I can add in the dependency list to the parent.pom and it will all work right now. -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 18 January 2012 10:56 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On 18 January 2012 06:35, Mark Collin m...@ardescosolutions.com wrote: I'm in the progress of writing my second attempt at providing a working maven solution which you can see here: It looks to me like an Ant build script using Maven deploy, i.e. Maven is not used for building. https://github.com/Ardesco/jmeter/tree/trunk/maven The sticking point I have at the moment is plugging in the dependencies, I have been looking at tweaking the existing ant script to use maven-ant-tasks, this is how far I have got (It doesn't work yet): https://github.com/Ardesco/jmeter/blob/trunk/build.xml Downloading the dependencies is trivial, however finding a nice way to specify individual jars for the classpaths and the release mechanism is not quite so tidy, the most sane way would seem to be a series of POM files to set the dependencies for each requirement but I'm not sure if that is changing the existing build process too much. Ant does not care about the dependencies being distributed accurately, so long as all the dependencies are present. AFAIK Maven need not either; if the parent depends on all the 3rd party libs, then every JMeter jar can depend on the parent. Intra-module dependencies in JMeter are quite simple and don't (generally must not) change. Today I was planning on having a look at building some dependency POM's for the maven deploy on the fly from the build.properties as maybe a saner way to do things which will won't touch the existing build.xml at all, although I'm not that happy with this solution either. Have you seen the POMs I comitted ro res/maven yesterday? I was planning on using Maven deploy to upload them to a SNAPSHOT repo. Someone can then see if the result is usable. -Original Message- From: Ian Brandt [mailto:i...@ianbrandt.com] Sent: 18 January 2012 05:04 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On Jan 17, 2012, at 4:10 PM, sebb wrote: IMO Maven works well for some projects, particularly single component (module) builds. Multi-module Maven does not work as well; in particular the test phase requires the project to be (re)installed first. Understood. I like Steve Ebersole's writeup of such issues he encountered with Hibernate [1]. On the other hand I maintain a 20 module Maven build at my company, having converted it from Ant a few years back, and have no regrets and minimal issues. JMeter dependencies don't tend to change very frequently, so the question is: is the effort required to introduce Ivy/MAT worth it? Good question, I can only offer anecdote. Before moving my company's build to Maven I first tried the Maven Ant Tasks and then Ivy. The situation was that we had a large (50+) and frequently changing list of direct and transient dependencies. With no way to comprehend all the relationships it was proving a maintenance nightmare to not use a dependency manager. MAT proved lacking in needed functionality at the time, so that attempt was short lived. With Ivy I can't remember the specifics, but I remember hitting enough issues and struggling with the documentation such that one day I just gave up and switched the entire build to Maven. I'd have to say that for either MAT or Ivy to be worth it they'd need to have matured since then. It's encouraging to see there is now Sonatype and Apache documentation on publishing to Maven repositories with them: [2], [3]. If JMeter has a small and unchanging set of dependencies then the situation is different. I'd only add that with any dependency management system the correctness of the declared relationships is everything, and with Maven you generally get one chance to get it right when publishing a given version to Central. Tomcat has fewer external dependencies than JMeter I believe, and yet in my experience the Tomcat POMs aren't always right. I'm proposing that MAT or Ivy might lead to higher quality POMs being published by JMeter because the exact same dependency information would be used to compile and test beforehand. I assume that the main build and release procedures would be unaffected? Is that correct? I've looked oven the Ant build, the README, and the Release Creation document on the Wiki [4]. Nothing jumps out as likely to be affected by MAT or Ivy
Re: Publishing to Maven Central
On 18 January 2012 05:04, Ian Brandt i...@ianbrandt.com wrote: On Jan 17, 2012, at 4:10 PM, sebb wrote: IMO Maven works well for some projects, particularly single component (module) builds. Multi-module Maven does not work as well; in particular the test phase requires the project to be (re)installed first. Understood. I like Steve Ebersole's writeup of such issues he encountered with Hibernate [1]. Just read it. Very useful summary; I've experienced nearly all of those issues in one way or another. [1] https://community.jboss.org/wiki/GradleWhy
RE: Publishing to Maven Central
I was trying to find a way that would use a unified dependency list for both the ant build and the maven deploy. The path I have been going down is creating a dependency POM for doc, core and api and making them required dependencies of ApacheJMeter_parent. I have then modified build.xml to use these dependencies instead of build.properties, but I'm running into issues with the existing classpath declaration in the build.xml because it doesn't just use all of the files in core, doc, or api. I'll upload what I currently have -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 18 January 2012 12:41 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On 18 January 2012 12:30, Mark Collin m...@ardescosolutions.com wrote: It looks like you have specified all of the dependencies in the ApacheJMeter_parent pom. I thought you wanted a unified set of dependencies that are only declared in one place. Ideally, yes, but that looks to be hard to do. This approach should be enough to publish the jars and it's not to hard to maintain. If it can be improved later, so much the better. The code I have right now will deploy to a repo using ant to call the mvn deploy command via an exec command. It's working on Linux and Windows and just requires you to have maven installed upon your system. Does it use standard Ant? Can you attach the file to the Bugzilla issue so I can try it? I can add in the dependency list to the parent.pom and it will all work right now. Huh? What's wrong with the existing dependency list in ApacheJMeter_parent pom? -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 18 January 2012 10:56 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On 18 January 2012 06:35, Mark Collin m...@ardescosolutions.com wrote: I'm in the progress of writing my second attempt at providing a working maven solution which you can see here: It looks to me like an Ant build script using Maven deploy, i.e. Maven is not used for building. https://github.com/Ardesco/jmeter/tree/trunk/maven The sticking point I have at the moment is plugging in the dependencies, I have been looking at tweaking the existing ant script to use maven-ant-tasks, this is how far I have got (It doesn't work yet): https://github.com/Ardesco/jmeter/blob/trunk/build.xml Downloading the dependencies is trivial, however finding a nice way to specify individual jars for the classpaths and the release mechanism is not quite so tidy, the most sane way would seem to be a series of POM files to set the dependencies for each requirement but I'm not sure if that is changing the existing build process too much. Ant does not care about the dependencies being distributed accurately, so long as all the dependencies are present. AFAIK Maven need not either; if the parent depends on all the 3rd party libs, then every JMeter jar can depend on the parent. Intra-module dependencies in JMeter are quite simple and don't (generally must not) change. Today I was planning on having a look at building some dependency POM's for the maven deploy on the fly from the build.properties as maybe a saner way to do things which will won't touch the existing build.xml at all, although I'm not that happy with this solution either. Have you seen the POMs I comitted ro res/maven yesterday? I was planning on using Maven deploy to upload them to a SNAPSHOT repo. Someone can then see if the result is usable. -Original Message- From: Ian Brandt [mailto:i...@ianbrandt.com] Sent: 18 January 2012 05:04 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On Jan 17, 2012, at 4:10 PM, sebb wrote: IMO Maven works well for some projects, particularly single component (module) builds. Multi-module Maven does not work as well; in particular the test phase requires the project to be (re)installed first. Understood. I like Steve Ebersole's writeup of such issues he encountered with Hibernate [1]. On the other hand I maintain a 20 module Maven build at my company, having converted it from Ant a few years back, and have no regrets and minimal issues. JMeter dependencies don't tend to change very frequently, so the question is: is the effort required to introduce Ivy/MAT worth it? Good question, I can only offer anecdote. Before moving my company's build to Maven I first tried the Maven Ant Tasks and then Ivy. The situation was that we had a large (50+) and frequently changing list of direct and transient dependencies. With no way to comprehend all the relationships it was proving a maintenance nightmare to not use a dependency manager. MAT proved lacking in needed functionality at the time, so that attempt was short lived. With Ivy I can't remember the specifics, but I remember hitting enough issues and struggling with the documentation such that one day I just gave up and
BUG 52048
Hello Sebb, Is it OK for you if I commit the patch once I have updated upgrade.properties or you want to close issue as wontfix ? Thanks. Regarding Mirror, in fact I had this bad ? :-) idea when debugging Cookie issue a while ago , I noticed lot of threads were being launched and Eclipse Debugger went crazy so I had to kill Eclipse. In my understanding of Mirror, it is just used during writing phase, so number of thread is low. If you want to put high numbers then in current implementation, JMeter performance will go really down since Thread creation has a big cost, so putting a limit on this is better on this point. Another use of this modification is that you can simulate Server refusing requests by putting a low value to Threads. I don't really understand in which case you will use a mirror in Batch Mode so an example will help me. I can rollback it all if you think it's a bad idea. Regards Philipe
Re: BUG 52048
On 18 January 2012 20:37, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello Sebb, Is it OK for you if I commit the patch once I have updated upgrade.properties or you want to close issue as wontfix ? If you can get it to work without breaking anything, then I have no objection. Documentation (screenshots and descriptions) also need to be updated. Seems like a lot of work for a minor visual improvement, but if you want to spend the time on it, go ahead. Thanks. Regarding Mirror, I will respond in a separate thread. (please use separate e-mails for separate topics)
Change to Mirror threading [was: BUG 52048]
On 18 January 2012 20:37, Philippe Mouawad philippe.moua...@gmail.com wrote: snip/ Regarding Mirror, in fact I had this bad ? :-) idea when debugging Cookie issue a while ago , I noticed lot of threads were being launched and Eclipse Debugger went crazy so I had to kill Eclipse. In my understanding of Mirror, it is just used during writing phase, so number of thread is low. Not sure what you mean by writing phase. I use it for debugging, e.g. seeing what is in a POST request. If you want to put high numbers then in current implementation, JMeter performance will go really down since Thread creation has a big cost, so putting a limit on this is better on this point. Possibly. Another use of this modification is that you can simulate Server refusing requests by putting a low value to Threads. Yes, that could be useful. I don't really understand in which case you will use a mirror in Batch Mode so an example will help me. See above (POST). I can rollback it all if you think it's a bad idea. As (I thought) I already wrote, I think it's a bad idea to change the default behaviour. Having an option to limit the threads and limit the queued requests would be useful. So I suggest making the default values 0, and only creating the thread pool and queue if the value is 0. Again, the documentation needs to be updated to describe how to use the new settings. Regards Philipe
Re: svn commit: r1233093 - in /jmeter/trunk/src/core/org/apache/jmeter: gui/action/Remove.java resources/messages.properties resources/messages_fr.properties
Hello,
I can add a property (in jmeter.properties) to revert to default
behavior (remove without confirmation) but I don't think it is necessary.
Milamber
Le 18/01/2012 22:18, milam...@apache.org a ecrit :
Author: milamber
Date: Wed Jan 18 22:18:57 2012
New Revision: 1233093
URL: http://svn.apache.org/viewvc?rev=1233093view=rev
Log:
Add a dialog box to confirm removing the element(s) when Remove action is
called
Modified:
jmeter/trunk/src/core/org/apache/jmeter/gui/action/Remove.java
jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
Modified: jmeter/trunk/src/core/org/apache/jmeter/gui/action/Remove.java
URL:
http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/gui/action/Remove.java?rev=1233093r1=1233092r2=1233093view=diff
==
--- jmeter/trunk/src/core/org/apache/jmeter/gui/action/Remove.java (original)
+++ jmeter/trunk/src/core/org/apache/jmeter/gui/action/Remove.java Wed Jan 18
22:18:57 2012
@@ -28,6 +28,7 @@ import javax.swing.tree.TreePath;
import org.apache.jmeter.gui.GuiPackage;
import org.apache.jmeter.gui.tree.JMeterTreeNode;
import org.apache.jmeter.testelement.TestElement;
+import org.apache.jmeter.util.JMeterUtils;
/**
* Implements the Remove menu item.
@@ -56,17 +57,24 @@ public class Remove implements Command {
}
public void doAction(ActionEvent e) {
-// TODO - removes the nodes from the CheckDirty map - should it be
done later, in case some can't be removed?
-ActionRouter.getInstance().actionPerformed(new
ActionEvent(e.getSource(), e.getID(), ActionNames.CHECK_REMOVE));
-GuiPackage guiPackage = GuiPackage.getInstance();
-JMeterTreeNode[] nodes =
guiPackage.getTreeListener().getSelectedNodes();
-TreePath newTreePath = // Save parent node for later
-guiPackage.getTreeListener().removedSelectedNode();
-for (int i = nodes.length - 1; i = 0; i--) {
-removeNode(nodes[i]);
+int isConfirm = JOptionPane.showConfirmDialog(null,
+JMeterUtils.getResString(remove_confirm_msg),// $NON-NLS-1$
+JMeterUtils.getResString(remove_confirm_title), //
$NON-NLS-1$
+JOptionPane.WARNING_MESSAGE,
+JOptionPane.YES_NO_OPTION);
+if (isConfirm == JOptionPane.YES_OPTION) {
+// TODO - removes the nodes from the CheckDirty map - should it
be done later, in case some can't be removed?
+ActionRouter.getInstance().actionPerformed(new
ActionEvent(e.getSource(), e.getID(), ActionNames.CHECK_REMOVE));
+GuiPackage guiPackage = GuiPackage.getInstance();
+JMeterTreeNode[] nodes =
guiPackage.getTreeListener().getSelectedNodes();
+TreePath newTreePath = // Save parent node for later
+guiPackage.getTreeListener().removedSelectedNode();
+for (int i = nodes.length - 1; i = 0; i--) {
+removeNode(nodes[i]);
+}
+
guiPackage.getTreeListener().getJTree().setSelectionPath(newTreePath);
+guiPackage.updateCurrentGui();
}
-
guiPackage.getTreeListener().getJTree().setSelectionPath(newTreePath);
-guiPackage.updateCurrentGui();
}
private static void removeNode(JMeterTreeNode node) {
Modified:
jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
URL:
http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties?rev=1233093r1=1233092r2=1233093view=diff
==
--- jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
(original)
+++ jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties Wed
Jan 18 22:18:57 2012
@@ -695,6 +695,8 @@ remote_start_all=Remote Start All
remote_stop=Remote Stop
remote_stop_all=Remote Stop All
remove=Remove
+remove_confirm_title=Confirm remove?
+remove_confirm_msg=Are you sure you want remove this element(s)?
rename=Rename entry
report=Report
report_bar_chart=Bar Chart
Modified:
jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
URL:
http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties?rev=1233093r1=1233092r2=1233093view=diff
==
--- jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
(original)
+++ jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
Wed Jan 18 22:18:57 2012
@@ -689,6 +689,8 @@ remote_start_all=D\u00E9marrage distant
remote_stop=Arr\u00EAt distant
remote_stop_all=Arr\u00EAt distant de tous
remove=Supprimer
RE: Publishing to Maven Central
Uploaded a final version just now. I had to fix some transitive dependency problems that were not apparent until you tried to use the artifacts and I had one POM that was not correctly referencing ApacheJMeter_parent. The final version will also automatically download ant-contrib if you don't have it to make the whole process easier. Let me know if it needs any more tweaking. Regards Mark -Original Message- From: Mark Collin [mailto:m...@ardescosolutions.com] Sent: 18 January 2012 14:10 To: dev@jmeter.apache.org Subject: RE: Publishing to Maven Central I was trying to find a way that would use a unified dependency list for both the ant build and the maven deploy. The path I have been going down is creating a dependency POM for doc, core and api and making them required dependencies of ApacheJMeter_parent. I have then modified build.xml to use these dependencies instead of build.properties, but I'm running into issues with the existing classpath declaration in the build.xml because it doesn't just use all of the files in core, doc, or api. I'll upload what I currently have -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 18 January 2012 12:41 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On 18 January 2012 12:30, Mark Collin m...@ardescosolutions.com wrote: It looks like you have specified all of the dependencies in the ApacheJMeter_parent pom. I thought you wanted a unified set of dependencies that are only declared in one place. Ideally, yes, but that looks to be hard to do. This approach should be enough to publish the jars and it's not to hard to maintain. If it can be improved later, so much the better. The code I have right now will deploy to a repo using ant to call the mvn deploy command via an exec command. It's working on Linux and Windows and just requires you to have maven installed upon your system. Does it use standard Ant? Can you attach the file to the Bugzilla issue so I can try it? I can add in the dependency list to the parent.pom and it will all work right now. Huh? What's wrong with the existing dependency list in ApacheJMeter_parent pom? -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 18 January 2012 10:56 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On 18 January 2012 06:35, Mark Collin m...@ardescosolutions.com wrote: I'm in the progress of writing my second attempt at providing a working maven solution which you can see here: It looks to me like an Ant build script using Maven deploy, i.e. Maven is not used for building. https://github.com/Ardesco/jmeter/tree/trunk/maven The sticking point I have at the moment is plugging in the dependencies, I have been looking at tweaking the existing ant script to use maven-ant-tasks, this is how far I have got (It doesn't work yet): https://github.com/Ardesco/jmeter/blob/trunk/build.xml Downloading the dependencies is trivial, however finding a nice way to specify individual jars for the classpaths and the release mechanism is not quite so tidy, the most sane way would seem to be a series of POM files to set the dependencies for each requirement but I'm not sure if that is changing the existing build process too much. Ant does not care about the dependencies being distributed accurately, so long as all the dependencies are present. AFAIK Maven need not either; if the parent depends on all the 3rd party libs, then every JMeter jar can depend on the parent. Intra-module dependencies in JMeter are quite simple and don't (generally must not) change. Today I was planning on having a look at building some dependency POM's for the maven deploy on the fly from the build.properties as maybe a saner way to do things which will won't touch the existing build.xml at all, although I'm not that happy with this solution either. Have you seen the POMs I comitted ro res/maven yesterday? I was planning on using Maven deploy to upload them to a SNAPSHOT repo. Someone can then see if the result is usable. -Original Message- From: Ian Brandt [mailto:i...@ianbrandt.com] Sent: 18 January 2012 05:04 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On Jan 17, 2012, at 4:10 PM, sebb wrote: IMO Maven works well for some projects, particularly single component (module) builds. Multi-module Maven does not work as well; in particular the test phase requires the project to be (re)installed first. Understood. I like Steve Ebersole's writeup of such issues he encountered with Hibernate [1]. On the other hand I maintain a 20 module Maven build at my company, having converted it from Ant a few years back, and have no regrets and minimal issues. JMeter dependencies don't tend to change very frequently, so the question is: is the effort required to introduce Ivy/MAT worth it? Good question, I can only offer anecdote. Before moving
Re: Publishing to Maven Central
On 18 January 2012 22:45, Mark Collin m...@ardescosolutions.com wrote: Uploaded a final version just now. I had to fix some transitive dependency problems that were not apparent until you tried to use the artifacts and I had one POM that was not correctly referencing ApacheJMeter_parent. The final version will also automatically download ant-contrib if you don't have it to make the whole process easier. I don't think we need the ant-contrib; so long as Maven is locally installed it's possible to access it using Java. I recently committed an Ant script that uses this technique to upload the jars (so far not source or javadoc). Let me know if it needs any more tweaking. Have you seen the snapshots I uploaded? Do the poms work OK? If not, what needs to be fixed? Regards Mark -Original Message- From: Mark Collin [mailto:m...@ardescosolutions.com] Sent: 18 January 2012 14:10 To: dev@jmeter.apache.org Subject: RE: Publishing to Maven Central I was trying to find a way that would use a unified dependency list for both the ant build and the maven deploy. The path I have been going down is creating a dependency POM for doc, core and api and making them required dependencies of ApacheJMeter_parent. I have then modified build.xml to use these dependencies instead of build.properties, but I'm running into issues with the existing classpath declaration in the build.xml because it doesn't just use all of the files in core, doc, or api. I'll upload what I currently have -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 18 January 2012 12:41 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On 18 January 2012 12:30, Mark Collin m...@ardescosolutions.com wrote: It looks like you have specified all of the dependencies in the ApacheJMeter_parent pom. I thought you wanted a unified set of dependencies that are only declared in one place. Ideally, yes, but that looks to be hard to do. This approach should be enough to publish the jars and it's not to hard to maintain. If it can be improved later, so much the better. The code I have right now will deploy to a repo using ant to call the mvn deploy command via an exec command. It's working on Linux and Windows and just requires you to have maven installed upon your system. Does it use standard Ant? Can you attach the file to the Bugzilla issue so I can try it? I can add in the dependency list to the parent.pom and it will all work right now. Huh? What's wrong with the existing dependency list in ApacheJMeter_parent pom? -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 18 January 2012 10:56 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On 18 January 2012 06:35, Mark Collin m...@ardescosolutions.com wrote: I'm in the progress of writing my second attempt at providing a working maven solution which you can see here: It looks to me like an Ant build script using Maven deploy, i.e. Maven is not used for building. https://github.com/Ardesco/jmeter/tree/trunk/maven The sticking point I have at the moment is plugging in the dependencies, I have been looking at tweaking the existing ant script to use maven-ant-tasks, this is how far I have got (It doesn't work yet): https://github.com/Ardesco/jmeter/blob/trunk/build.xml Downloading the dependencies is trivial, however finding a nice way to specify individual jars for the classpaths and the release mechanism is not quite so tidy, the most sane way would seem to be a series of POM files to set the dependencies for each requirement but I'm not sure if that is changing the existing build process too much. Ant does not care about the dependencies being distributed accurately, so long as all the dependencies are present. AFAIK Maven need not either; if the parent depends on all the 3rd party libs, then every JMeter jar can depend on the parent. Intra-module dependencies in JMeter are quite simple and don't (generally must not) change. Today I was planning on having a look at building some dependency POM's for the maven deploy on the fly from the build.properties as maybe a saner way to do things which will won't touch the existing build.xml at all, although I'm not that happy with this solution either. Have you seen the POMs I comitted ro res/maven yesterday? I was planning on using Maven deploy to upload them to a SNAPSHOT repo. Someone can then see if the result is usable. -Original Message- From: Ian Brandt [mailto:i...@ianbrandt.com] Sent: 18 January 2012 05:04 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On Jan 17, 2012, at 4:10 PM, sebb wrote: IMO Maven works well for some projects, particularly single component (module) builds. Multi-module Maven does not work as well; in particular the test phase requires the project to be (re)installed first. Understood. I like Steve Ebersole's writeup
Toolbar Polish
Hey Guys, I just built trunk for the first time in awhile and the on-by-default toolbar could use some work. -- icons are kinda 8-bit windowish -- Reset Search doesn't work -- Search button doesn't work again until Reset Search is called. -- Why do we have a close and a new? They seem to do the same thing? -- Some buttons/Actions could be simplified(merge Start/Stop icons) Is this feature still being worked or should I be opening bugs for these items? Thanks, Anthony
Re: svn commit: r1233097 - in /jmeter/trunk: docs/images/screenshots/changes/ xdocs/ xdocs/images/screenshots/changes/
Yes, very good indeed ! Thanks On Thu, Jan 19, 2012 at 2:47 AM, sebb seb...@gmail.com wrote: On 18 January 2012 22:29, milam...@apache.org wrote: Author: milamber Date: Wed Jan 18 22:29:54 2012 New Revision: 1233097 URL: http://svn.apache.org/viewvc?rev=1233097view=rev Log: Add New and Noteworthy for next version (2.6) Looks very good, thanks! -- Cordialement. Philippe Mouawad.
RE: Publishing to Maven Central
Sebb, There is a transitive dependency issue with JDOM pulling in jaxen which by default tries to pull in some plugins that are not available: http://blog.cedarsoft.com/2011/12/fixing-maven-artifact-jaxen/ http://jira.codehaus.org/browse/JAXEN-217 This is fixed in the package I supplied yesterday by adding an exclusion for jaxen. I have also added in a repo that has jchart 0.75 available, and one for beanshell 2.0b5 (although checking just now I have missed the dependency block for beanshell in the parent POM so it isn't actually pulling beanshell down). I'll look at it in a bit more anger in a couple of hours to provide some more useful feedback. Ant-contrib is used in the patch I have supplied to loop through a couple of lists and add in an if/else block that will allow you to choose if you want to add sources and javadoc jars when deploying, if you don't want to do these things it isn't needed. Regards Mark -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 18 January 2012 23:39 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On 18 January 2012 22:45, Mark Collin m...@ardescosolutions.com wrote: Uploaded a final version just now. I had to fix some transitive dependency problems that were not apparent until you tried to use the artifacts and I had one POM that was not correctly referencing ApacheJMeter_parent. The final version will also automatically download ant-contrib if you don't have it to make the whole process easier. I don't think we need the ant-contrib; so long as Maven is locally installed it's possible to access it using Java. I recently committed an Ant script that uses this technique to upload the jars (so far not source or javadoc). Let me know if it needs any more tweaking. Have you seen the snapshots I uploaded? Do the poms work OK? If not, what needs to be fixed? Regards Mark -Original Message- From: Mark Collin [mailto:m...@ardescosolutions.com] Sent: 18 January 2012 14:10 To: dev@jmeter.apache.org Subject: RE: Publishing to Maven Central I was trying to find a way that would use a unified dependency list for both the ant build and the maven deploy. The path I have been going down is creating a dependency POM for doc, core and api and making them required dependencies of ApacheJMeter_parent. I have then modified build.xml to use these dependencies instead of build.properties, but I'm running into issues with the existing classpath declaration in the build.xml because it doesn't just use all of the files in core, doc, or api. I'll upload what I currently have -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 18 January 2012 12:41 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On 18 January 2012 12:30, Mark Collin m...@ardescosolutions.com wrote: It looks like you have specified all of the dependencies in the ApacheJMeter_parent pom. I thought you wanted a unified set of dependencies that are only declared in one place. Ideally, yes, but that looks to be hard to do. This approach should be enough to publish the jars and it's not to hard to maintain. If it can be improved later, so much the better. The code I have right now will deploy to a repo using ant to call the mvn deploy command via an exec command. It's working on Linux and Windows and just requires you to have maven installed upon your system. Does it use standard Ant? Can you attach the file to the Bugzilla issue so I can try it? I can add in the dependency list to the parent.pom and it will all work right now. Huh? What's wrong with the existing dependency list in ApacheJMeter_parent pom? -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 18 January 2012 10:56 To: dev@jmeter.apache.org Subject: Re: Publishing to Maven Central On 18 January 2012 06:35, Mark Collin m...@ardescosolutions.com wrote: I'm in the progress of writing my second attempt at providing a working maven solution which you can see here: It looks to me like an Ant build script using Maven deploy, i.e. Maven is not used for building. https://github.com/Ardesco/jmeter/tree/trunk/maven The sticking point I have at the moment is plugging in the dependencies, I have been looking at tweaking the existing ant script to use maven-ant-tasks, this is how far I have got (It doesn't work yet): https://github.com/Ardesco/jmeter/blob/trunk/build.xml Downloading the dependencies is trivial, however finding a nice way to specify individual jars for the classpaths and the release mechanism is not quite so tidy, the most sane way would seem to be a series of POM files to set the dependencies for each requirement but I'm not sure if that is changing the existing build process too much. Ant does not care about the dependencies being distributed accurately, so long as all the dependencies are present. AFAIK Maven need not either; if the
Re: Toolbar Polish
Hello, Le 19/01/2012 04:56, Anthony Johnson a ecrit : Hey Guys, I just built trunk for the first time in awhile and the on-by-default toolbar could use some work. -- icons are kinda 8-bit windowish Yes, icons comes from src/core/org/apache/jmeter/images, which are a old set of icons. If you have a new set of icons with better design/quality, we are interested. -- Reset Search doesn't work Works for me. (Debian 6 with JDK 5/6, Windows XP with JDK 6) -- Search button doesn't work again until Reset Search is called. Works too. -- Why do we have a close and a new? They seem to do the same thing? Yes same action. I think that have a New and Close allow a better user friendly for JMeter users (particular for new users). Theses icons are traditional in a toolbar and permit to new people to have some marks -- Some buttons/Actions could be simplified(merge Start/Stop icons) Yes, possibly. Is this feature still being worked or should I be opening bugs for these items? Currently, no works planned. Milamber Thanks, Anthony
Re: Time for a release?
Hello, I can act as a release manager for the 2.6 version. Milamber Le 15/01/2012 14:27, Milamber a ecrit : Le 15/01/2012 12:58, Rainer Jung a ecrit : Hello everyone, at the beginning of December 2011 we discussed, whether we should have a release soon. I think the overall opinion was yes but it seems the project is still busy with fixing things and adding enhancements. Nevertheless I have the impression there are now enough changes to warrant the next release and get all the nice new stuff out in users hands. I don't know whether it should be a 2.5.2 or 2.6 though. +1 to release a new version 2.6 Milamber Kudos to all the effort you put into JMeter! Regards, Rainer
