On Sat, Dec 5, 2015 at 12:41 PM, sebb <[email protected]> wrote: > On 5 December 2015 at 09:25, Philippe Mouawad > <[email protected]> wrote: > > Hello, > > I open this thread to discuss what could be done to favor new comers > > contributions and increase patches contributions. > > > > After discussion with colleagues that came recently on project with a > > "Standard project" background, the following ideas came: > > > > - Ease IDE Setup (see below for details) > > - Change http://jmeter.apache.org/svnindex.html to mention GITHUB > mirror > > , the link would be renamed to Source Repositories > > +1 > > > - Add fork us on Github on project if acceptable by Apache policy > > +0 > > > - Create a Developers page similar to > > http://cloudstack.apache.org/developers.html, explaining how to > > contribute a PR > > +1 > > > - Find an alternative to Ant > > -1 > > > > > Ease IDE Setup: > > Regarding IDE Setup and particularly Eclipse: > > 1/ As we don't have Maven (mvn eclipse:eclipse) setting up Dev > Environment > > for new comers is not a nowadays "standard". > > Maybe Graddle could be an alternative (Maven having been set aside in a > > previous dev discussion), it allows providing Eclipse Project Model, is > > used by big projects like Spring Frameworks and seems to be very > flexible , > > using Groovy > > Yes, it is flexible, but it is hard to get it right for such a large > code base as JMeter. > > My experience of it is that it can be very hard to find out where > things are happening. > Precisely because of the flexibility. > > > 2/ If we decide to stay on Ant, we should have an HTML page instead of > > eclipse.readme which can easily be missed. > > +1 > > > The page should be enhanced to mention requirements like Java 7 and > > Compiler compliance level.... > > Of course. > > > 3/ Running JUnit tests should also be documented, particularly running > them > > directly from IDE > > +1 > > Some of the tests don't work very well from the IDE and need > additional settings. > There is an abstract test class that tries to fix these issues but > it's not fully integrated. > > > 4/ If we stay with Ant, why not also distribute eclipse.project so that > we > > could create an ant task that: > > The problem is that the Eclipse .project file varies between installations. > If the developer adds Findbugs or Checkstyle etc that will affect the > .project file. > Likewise if they have several JDKs and JMeter is not using the default. > > However it would be possible to create a default one if it does not exist. > It may need tweaking. > Ok did it this way
> > > a) renames eclipse.classpath to .classpath > > -1 to rename; copy would be OK if it does not already exist > Ok did it this way > > > b) renames eclipse.project to .project > > -1 to rename; copy would be OK if it does not already exist > Ok did it this way > > > c) Call download_jars , > > -1, this must be a separate action. > Maven downloads without asking, why is it a problem to do so ? > It's important that users 'agree' to the download. > For now I added an agreement and fail if it does not come > > However the Eclipse copy task could print a message to remind users to > download. > And vice versa. > Added this if user refuses download agreement > > > This way project could be imported in Eclipse much more easily and less > > manually > > > > > Regards > > Philippe M. > -- Cordialement. Philippe Mouawad.
