It seems the real problem here is the large amount of jars checked
into the repository. What about something that just does dependency
management, for example apache ivy?

Does maven solve any other problems we have that make it worth going
all the way with it? I'm worried it could cause as much trouble as it
solves. I'm not fundamentally against it but I'd like to be confident
there are solid reasons/benefits to the waveprotocol project for
migrating to maven.

My 2c.

Dan

Στις 27 Απριλίου 2011 7:51 π.μ., ο χρήστης Michael MacFadden
<[email protected]> έγραψε:
> Nelson,
>
> I am all for this.  I am very experienced with Maven and the proper ways to 
> set up multi module projects including dependency management, etc.  I think 
> your assessment of the situation is correct.  We would ultimately need a code 
> free to get this done.
>
> However, before you go to far, I would try to get a real discussion going on 
> if this is something the team wants to do.  If so we need to discuss what the 
> right modules are, what artifact and group ids we would want, etc.  I would 
> hate to see you set up a lot of poms.xml that don't line up with how we would 
> ultimately do things.
>
> As a side note, if we did want to go to maven, now would be the right time.  
> Everything else has to be migrated anyway, might as well take the hit now.  
> However, I would recommend that we get the current source migrated over first.
>
> ~Michael
>
>
> On Apr 26, 2011, at 10:12 AM, Nelson Silva wrote:
>
>> Hi all,
>>
>> There have been several discussions on adding maven as a build tool.
>>
>> I've decided to start working on this by adding a tools/maven subdirectory 
>> with a multimodule project layout.
>> I pushed my ongoing work to a branch in my GitHub clone :
>>
>> https://github.com/nelsonsilva/wave-protocol/tree/maven/tools/maven
>>
>> While a complete port to maven as the main build tool would required a code 
>> freeze and a healthy discussion of code reorganization into proper modules 
>> we should be able to use a simple includes/excludes approach for now and in 
>> the end, if everyone is ok with it, we could easily make the port happen.
>>
>> I would like to get some help with this from everyone who's interested. 
>> There are lots of plugins and lots of ways to acomplish things in maven so 
>> this should get the discussion started.
>>
>> I chose to go with GitHub so everyone can fork it and send me pull requests. 
>> If you'd rather go with the issue/patchset approach I'll open the issue but 
>> the idea here was to have several people contribute and not a single patch + 
>> review process.
>>
>> Quickstart:
>>
>> cd tools/maven
>> ./install_deps.sh # This will install a couple of dependencies that were 
>> either patched or were not found in existing maven repos
>> mvn install
>> cd server
>> ln -s ../../../war
>> mvn exec:java # This should start the server, although you'll have to 
>> symlink the war directory for now
>>
>> TO DO:
>>
>> - Use profiles for dev/prod
>> - Remove as many ant tasks as possible and use pure maven plugins
>> - Use the assembly plugin to package the server with the webclient
>> - Setup the surefire tests for each module
>> - Rethink the modules, we should have pure api modules and the several impl 
>> modules for persistence, websockets, auth, etc ...
>> - etc....
>>
>> Looking forward to getting this going...
>>
>> Regards,
>>
>>    Nelson Silva
>
>

Reply via email to