On Jul 25, 2010, at 9:54 AM, Peter Janes wrote: > There's also > org.codehaus.mojo:build-helper-maven-plugin:reserve-network-port, which only > assigns random ports (unlike port-allocator, which allows the use of explicit > ports). > > I'm hesitant to put this next bit forward, given Jason's implicit approval of > the "POM expression" approach, but what the heck. >
I was just pointing Kristian at code I know about. > To date it's appeared that the parallelization effort has been more toward > determining the possibilities for parallel execution from what's in the POM > rather than changing the POM (or the way it's processed) to support > parallelization. Adding "magic well-known properties" to the POM doesn't > seem to be in the spirit of Maven: most of the well-known properties that are > present today are declarative (project.* defined by the POM, settings.* by > the settings.xml file), and everything else is either environment-dependent > or set by plugins. > > Wouldn't it be more appropriate to encourage tasks that require ports to > allocate their own in a parallel-safe manner? If we end up having N plugins wanting to do this it would probably make sense to create a shared component for doing this so that we'd know these N plugins wouldn't be stepping on each others' toes. So take the code that seems most appropriate and make it a component. We could also wrap it and make a plugin if that's required too. > It could be a condition for marking them @threadSafe, or entered as a bug if > they've already been marked as such. Alternatively, if the ports need to be > shared as properties, perhaps it would be appropriate to add a standard > plugin execution to the default lifecycle (in "initialize", presumably). > > On 25/07/10 07:54 AM, Jason van Zyl wrote: >> We created something for the Nexus testing that we could extend or further >> generalize: >> >> http://svn.sonatype.org/plugins/trunk/port-allocator-maven-plugin/ >> >> On Jul 25, 2010, at 5:26 AM, Kristian Rosenvold wrote: >> >>> The most popular problem when converting to parallel seems to be >>> allocation of TCP/IP port numbers per-module. Where builds would be >>> using one shared port-number across all modules, they now need distinct >>> port-numbers. >>> >>> A solution I can think of is to make a pom expression like >>> ${dynamicPortNumber} that'd be bound to something like a base port >>> number + indexOf(currentModule). Then you'd need to define a base port >>> number somewhere. >>> >>> Ultimately I can even see that this'd be a service that plugins like >>> parallel surefire could also want to use, but I think /that/ could >>> probably wait for later. >>> >>> But I'm sure you guys have a better solution as to how to implement the >>> pom-based feature ;) >>> >>> Currently catching up with Julia wrt # vacation days. >>> >>> Kristian >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> Simplex sigillum veri. (Simplicity is the seal of truth.) >> >> >> >> > > > -- > "Fighting a war is easy. Destroying is easy. Building a new world out of > what's left of the old, that is what's hard." —J. Michael Straczynski > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
