Hi All,! Nice to see that we are moving on with a constructive discussion and Michael, thanks for laying out the basics of how a community can work so clearly! Yuri, thanks for laying out the process structure, probably this is the process we should follow whenever someone comes up with a new idea. He takes the ownership, gather a group around the idea, involves a contributor and gets the idea in the project. :)
Well, to move on... Nelson, I worked thursday night and part of friday to reorganize the then checkout to a maven build format... of course taking a lot from your maven project, but following the currently builds output modules generated by ant dist. I am sure, this is very crude with some work remaining, but I did this in hardly 5-6 hours. If we give it time and take a shot together we can put it out in a day or two ready for review. I wanted to stretch on and complete it but am running fever since friday evening... I have no idea, how the process will go further but anytime you decide to pick up this task, I'll happily contribute in any way possible. I'll take a shot at it once more monday night (India) to atleast get a working build. please take a look at this - https://github.com/rohit-tingendab/Mavenized-Wave-In-A-Box and let me know your thoughts. Regards, Rohit The diamond cannot be polished without friction, nor man perfected without trials http://mytechrantings.blogspot.com On Sun, May 1, 2011 at 12:37 AM, Michael MacFadden < [email protected]> wrote: > Yuri, > > Totally agree. Thanks for structuring this in this way. > > > Nelson, > > Let's start another thread to discuss how a possible maven migration might > go. Why don't you start with your current ideas. Those who want can > participate in the discussion. I can capture a "plan" in our development > wiki, which needs to get set up anyway. > > ~Michael > > > On Apr 30, 2011, at 9:44 AM, Yuri Z wrote: > > > Ok, I think you got good points that send us back to a constructive > > discussion. > > I think that we should proceed in the following fashion: > > 1. Those who want to move to maven should organize and openly declare > that > > they are committed to the task. There should be at least one existing > Apache > > Wave committer in the group as someone who already demonstrated its merit > > and ability to deliver. It will also ensure that there will be someone > > available to review the changes and push them. > > 2. The "Maven" group should produce a plan with measurable milestones. > The > > plan should state the task, amount of effort, timeline, and who is > assigned > > to which task. > > 3. At this point we will be able to discuss this concrete suggestion and > > make a vote. > > > > 2011/4/30 Michael MacFadden <[email protected]> > > > >> All, > >> > >> I think we have gotten a little off track on the maven discussion. What > it > >> has basically boiled down to is a discussion on if we should migrate to > >> maven or spend time working on other items. I don't think this is the > right > >> way to look at it at the moment. Here are my thoughts. > >> > >> 1) > >> We should asses whether maven is even something we like regardless of > the > >> effort it takes. What are the merits of maven? Do we agree that there > >> would be a benefit? Assuming zero effort would we want maven? If the > >> answer is no, then everything else is irrelevant. I think we need to > have > >> an objective conversation about this first. > >> > >> 2) > >> We are assuming that there is a choice between doing the work to > "mavenize" > >> the project vs. doing some other work that people feel is more > important. > >> The major flaw here is that assumes that the resources that would do the > >> maven work would otherwise do something else. Although we are a > community > >> that should come to a consensus on priorities, we need to remember that > we > >> are also just individual committers. We can't force and individual to > work > >> on anything specific. If there is one or more resources out there who > want > >> to work on brining maven to the project we can't simply tell them "no" > if > >> the only reason is that we would prefer that they would work on > something > >> else. It's quite possible that the people that want to work on brining > >> maven to the project wouldn't work on other things even if we asked them > to. > >> > >> In other words if in point #1 we decide that we do want to go with maven > >> eventually (a big if), and there is some one out there who is > volunteering > >> to help us with that now, we shouldn't discourage them. Consider the > >> non-commiter who has a project that uses maven. That person might want > to > >> use WiaB components in his project. He might write a patch that > mavenizes > >> the project and send it to us. In that case we haven't lost out on > working > >> on any other functionality. > >> > >> > >> 3) > >> So if we do want maven (point #1), and "WE" don't have to stop working > on > >> "OUR" priorities to get it because some one else is offering to do the > work > >> (point #2), then the last question is how disruptive would switching to > >> maven be on the rest of the development process. This could be the > tricky > >> part. Depending on how its done it could be very disruptive, or it > could be > >> fairly painless. If there was a way to slowly introduce maven, without > much > >> impact to the current development tasks then maybe we would be more > inclined > >> to do it. If everyone has to stop what they are doing for two weeks > while > >> we sort it out, then maybe not. > >> > >> Point being this is another area where some discussion would be very > >> helpful. > >> > >> > >> > >> Anyway, I would really like to have objective conversations about > point's > >> #1 and #3 and to move away from the "doing X right now should be more of > a > >> priority" conversation that we have gotten in to. While I agree that > >> priorities are important, and we need to start setting them for the > project, > >> I think we need to look at this from a ROI perspective first, and then > >> figure out where it fits on the roadmap given the project impact and the > >> resources that would need to be involved. Just my opinion. > >> > >> > >> ~Michael > >> > >> > >> On Apr 29, 2011, at 1:59 AM, Daniel Danilatos wrote: > >> > >>> Hi guys, > >>> > >>> I am inclined to agree with Yuri and STenyaK (forgive me I'm not sure > >>> what your first name is). Right now what this project needs most is > >>> some real momentum in terms of features and stability, and major > >>> refactorings of the code base merely to change build system seem like > >>> far too big a risk. I think any effort to port to maven would be much > >>> better spent on directly addressing the one or two most annoying pain > >>> points, such as making the build or unit tests run more incrementally, > >>> or exporting maven targets (so other projects that use maven can > >>> depend on our code). I am confident someone could get that fixed with > >>> a few hours work or less. Other benefits listed are far less concrete > >>> and don't seem worth the risk to me right now. I have no doubt that > >>> when we have a cool product, people will jump on board regardless of > >>> what build system we are using - it would be a bad sign for our > >>> project if it is the build system that is what attracts/repels > >>> contributors. > >>> > >>> Regarding maven itself (I'll try to be brief-ish until I collect my > >>> thoughts further): From what I can tell, reading people's opinions > >>> here and on the internet at large, there are two broad reasons why > >>> people seem to like maven. (1) it automates fetching dependencies, > >>> which is an annoying task to do manually. (2) it is an improvement > >>> over "normal" ant monolithic builds, by breaking applications down > >>> into modules and forbidding circular dependencies. Regarding (1), I > >>> can see how this can improve a lot of things, but I can also see how > >>> it adds more points of failure for a build setup. So it's not quite a > >>> dead-clear win. Regarding (2), I am a big fan, and you'll notice that > >>> we've tried hard to do that in the client code with fine-grained GWT > >>> module dependencies. Internally at Google, our build system > >>> encourages/enforces this. In both these examples, the module breakdown > >>> is fine-grained (often on the package-level), and this really makes > >>> sure you don't screw up, and helps keep code highly decoupled. Also, > >>> doing this is very lightweight - all you need is a small file that > >>> declares the deps. If you have a section of your code base that is > >>> well written with good dependency injection, adding these module > >>> declarations is a snap - it requires no code change or refactorings. > >>> The problem I see with maven is that modules seem to be quite heavy > >>> weight, and harder to split/join/move around. Please correct me if I'm > >>> wrong, but it seems that each module requires its own separate source > >>> tree, with a deep set of top level directory and other "boilerplate" - > >>> or, alternatively, fighting maven to maintain some other directory > >>> structure (but the consensus on the internet is that you don't fight > >>> maven unless you're a masochist). > >>> > >>> Full disclaimer: I have only used maven a little, and done a bunch of > >>> reading. But please don't discount my opinion on those grounds. Also, > >>> I hate ant, don't get me wrong. > >>> > >>> I do not in any way intend to start a "maven is awesome" vs "maven > >>> sucks" religious war here. My opinions above regarding maven are > >>> tentative, and I would love to revisit them. I provided them partly to > >>> play the devil's advocate, and partly to justify why I feel it's not a > >>> clear win to migrate, and so probably not worth the risk to the > >>> project's momentum until we are healthily going full steam ahead. At > >>> that point it'd be great to revisit this question and learn more about > >>> maven. I think ultimately whatever pleases the majority of the active > >>> contributors is best. > >>> > >>> Dan > >>> > >>> Στις 29 Απριλίου 2011 3:10 π.μ., ο χρήστης STenyaK <[email protected]> > >> έγραψε: > >>>> In the end, long term plans have to take into account the consequences > >> of > >>>> trying to future-proof the project: If focusing on long-term future > >> during > >>>> 2011 makes wave lose (or "not increase") the precious momentum it has > >> thanks > >>>> to inertia of googlers and other interested parties, then maybe it is > >>>> actually *not* such a good long-term plan. > >>>> > >>>> Just to put things in perspective: the project has blindly migrated > from > >> git > >>>> to svn, and accepted not to dog-feed itself, but is now considering > >> changing > >>>> a (afaik) perfectly working build system, which will disrupt > development > >> for > >>>> an unknown period of time. Also, time is being wasted in this > >>>> bike-shed-color discussion (ehm, sorry for contributing to it O:-). > >>>> > >>>> IMO continuing with ant for a few more weeks/months is probably going > to > >> be > >>>> better in the *actual* long term. > >>>> > >>>> 2011/4/28 Yuri Z <[email protected]> > >>>> > >>>>> Michael > >>>>> I hate to be the devil's advocate, but I ll take the role this time. > >>>>> First of all, you are right of course - all decisions should be > wighted > >> on > >>>>> the base of effort vs. gain and after analysis of the risks. > >>>>> Also, the analysis should build on the past relevant experiences. So > >> let's > >>>>> try to understand what happened with the move to Apache (sorry if I > >> kick a > >>>>> sacred cow). I think that the move to Apache is positive development, > >> but > >>>>> much ahead of the time. > >>>>> At the time I advocated to postpone the move because: "There are no > >>>>> immediate gains for the Wave in a Box project, but the prices are > >>>>> immediate". I mentioned that we should first > >>>>> > >>>>> - To focus on attaining the goals outlined in the WIAB roadmap > >>>>> - Use of Apache mailing list instead of dog food WIAB instance is a > >> very > >>>>> heavy price. > >>>>> - The move will take too much effort that instead can be devoted to > >>>>> development of core WIAB features. > >>>>> > >>>>> I was told then that: > >>>>> > >>>>> - The move will possibly attract an influx of commiters - didn't > >> happen. > >>>>> - It will be probably possible communicated with Apache so allow us > >> to > >>>>> use dog food instance instead - didn't happen > >>>>> - The move to Apache infra can be done in parallel and won't affect > >>>>> ongoing development efforts - not quite true. > >>>>> > >>>>> And it is clear that giving up on dog food instance - is a really > heavy > >>>>> price. Off course, the move could take only a few hours or days, but > in > >>>>> reality it taken 4 months and counting. > >>>>> So I think the lessons that we should learn: > >>>>> > >>>>> - Focus on the main product, do things only when necessary and not > >> ahead > >>>>> of time to gain possible value. > >>>>> - Don't assume that problems can be solved later, either have a > clean > >>>>> > >>>>> > >>>>> 2011/4/28 Michael MacFadden <[email protected]> > >>>>> > >>>>>> Yuri, > >>>>>> > >>>>>> I don't think we can view it as to high a price right now vs later. > >> The > >>>>>> fact of the matter is that if we push it off to some later date when > >> we > >>>>> will > >>>>>> have "free time" to take on something like this, it will honestly > >> never > >>>>> get > >>>>>> done. Plus we haven't quantified how much effort it would take. > What > >> if > >>>>> it > >>>>>> could get done in a few hours? Would it be worth it then? What > about > >> a > >>>>> few > >>>>>> days? I think the benefits are pretty clear, but we need to > quantify > >> how > >>>>>> much work it would take to get it done. > >>>>>> > >>>>>> Only then can we decide if it's worth it. One plug for doing it now > >>>>> rather > >>>>>> than after a "1.0" would be I imaging that a 1.0 release would be > >> ready > >>>>> for > >>>>>> a lot more wide spread use. If you imagine that you could see a lot > >> more > >>>>>> people downloading and using WiaB after 1.0. At that point we will > be > >>>>>> getting a lot more attention and enhancement and bug requests. We > >> might > >>>>>> even get an influx of committers. At that point it would be almost > >>>>>> impossible to justify a code freeze for a few days to switch to > maven. > >>>>>> > >>>>>> In my view we are almost in a now or never type of scenario. > >>>>>> > >>>>>> ~Michael > >>>>>> > >>>>>> > >>>>>> On Apr 28, 2011, at 12:09 AM, Yuri Z wrote: > >>>>>> > >>>>>>> IMHO code freeze price is too high for now. Maybe after we release > >> ver > >>>>>> 1.0 > >>>>>>> then ver 1.1 can be about moving to maven. > >>>>>>> > >>>>>>> 2011/4/28 Eric Charles <[email protected]> > >>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I've been paid for 6 months by one of my client to migrate > numerous > >>>>>> project > >>>>>>>> from ant to maven. Some were trivial, other were really > complicated > >>>>> due > >>>>>> to > >>>>>>>> legacy technologies,... and needed code refactoring. > >>>>>>>> > >>>>>>>> At the end, the result we got much more > >> manageable/testable/deployable > >>>>>>>> components based applications. > >>>>>>>> > >>>>>>>> I don't know wave code, but I bet maven compared to ivy will drive > >> to > >>>>> a > >>>>>>>> better code base, even if the prices may be high (work, > freeze,...). > >>>>>>>> > >>>>>>>> Tks, > >>>>>>>> - Eric > >>>>>>>> > >>>>>>>> > >>>>>>>> On 28/04/2011 06:34, Rohit Rai wrote: > >>>>>>>> > >>>>>>>>> +1 for migrating to maven > >>>>>>>>> > >>>>>>>>> Though I share the concern raised by Michael, "it is not going to > >> be > >>>>>> easy" > >>>>>>>>> (have experience in earlier changing from monolithic ant builds > to > >>>>>> modular > >>>>>>>>> maven builds...) and it will disrupt the development temporarily. > >>>>>>>>> > >>>>>>>>> But as mentioned in the mails above, we should think on these > line > >> - > >>>>>>>>> > >>>>>>>>> 1. Maven being the accepted build standard on date, will make it > >> easy > >>>>>> for > >>>>>>>>> new developers to start with WIAB. > >>>>>>>>> 2. Developers can pick a module and focus on working with it > rather > >>>>>> than > >>>>>>>>> spending time trying to understand the current project format > and > >>>>>>>>> figuring > >>>>>>>>> out what goes where. > >>>>>>>>> 3. It will make it easy for developers to integrate WIAB > components > >>>>>>>>> individually and also to embed WIAB in there applications. > >>>>>>>>> 4. IDE integration is very helpful to start of quickly > >>>>>>>>> > >>>>>>>>> At this point when Google is removing people from this project, I > >>>>> think > >>>>>> it > >>>>>>>>> makes sense for us to make it easy for any newbie coming to get > >>>>> started > >>>>>> on > >>>>>>>>> it, the more the merrier! > >>>>>>>>> > >>>>>>>>> And if we don't do it now, > >>>>>>>>> 1. that we are transferring it from Google Code to Apache (when > we > >>>>> can > >>>>>>>>> have > >>>>>>>>> a scheduled downtime for a couple of days) > >>>>>>>>> 2. the code base is manageable size > >>>>>>>>> 3. the contributors are limited in number > >>>>>>>>> > >>>>>>>>> We may never have an better opportunity and it is going to be > "much > >>>>>> more > >>>>>>>>> difficult" once the codebase and number of committers grow! > >>>>>>>>> > >>>>>>>>> Just my 2 cents from past experiences . . . > >>>>>>>>> > >>>>>>>>> And to back up my words, I will be all willing to spare couple of > >>>>> days, > >>>>>>>>> taking leave from my day job and weekend along if required to > >> assist > >>>>>> with > >>>>>>>>> the migration to maven. > >>>>>>>>> > >>>>>>>>> Note: If we have to move to maven, we should first list out what > >> will > >>>>>> be > >>>>>>>>> the > >>>>>>>>> modules and then what part of code goes into which module. This > >> will > >>>>>> speed > >>>>>>>>> up the actual transition process. > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Rohit > >>>>>>>>> > >>>>>>>>> The diamond cannot be polished without friction, nor man > perfected > >>>>>> without > >>>>>>>>> trials > >>>>>>>>> http://mytechrantings.blogspot.com > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Thu, Apr 28, 2011 at 8:52 AM, Michael MacFadden< > >>>>>>>>> [email protected]> wrote: > >>>>>>>>> > >>>>>>>>> All, > >>>>>>>>>> > >>>>>>>>>> I am not sold on maven at this point. Don't get me wrong I am a > >>>>>> strong > >>>>>>>>>> advocate of Maven, and although it has its issues, I think it > can > >> be > >>>>> a > >>>>>>>>>> big > >>>>>>>>>> benefit to a project. I am just not sold that it is worth the > >>>>> effort > >>>>>> at > >>>>>>>>>> the > >>>>>>>>>> moment. That being said here are a couple ways which maven > could > >>>>> help > >>>>>>>>>> the > >>>>>>>>>> wave in a box project: > >>>>>>>>>> > >>>>>>>>>> Modularization > >>>>>>>>>> > >>>>>>>>>> Maven encourages the construction of distinct modules for a > >> project. > >>>>>> As > >>>>>>>>>> the wave project grows, we will likely want to build a set of > >>>>> reusable > >>>>>>>>>> components that other projects could use. For example we may > have > >>>>>>>>>> concurrency control stacks, protocol stacks, interface > components, > >>>>> etc > >>>>>>>>>> that > >>>>>>>>>> other projects might want to take advantage of. We have already > >>>>>> gotten > >>>>>>>>>> request to use the editor, and we know people are interested in > >>>>>> building > >>>>>>>>>> new > >>>>>>>>>> UI's leveraging the client server protocol. With maven, the > >> project > >>>>>> can > >>>>>>>>>> easily be organized such that these modules are reference-able > and > >>>>>> usable > >>>>>>>>>> by > >>>>>>>>>> others. Things like the Robot and Gadget API are obvious > >> examples. > >>>>>>>>>> > >>>>>>>>>> This could be done without maven, but maven makes this the norm > >>>>> rather > >>>>>>>>>> than > >>>>>>>>>> the exception. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Build Time > >>>>>>>>>> > >>>>>>>>>> Right now we have a pretty monolithic build. When I change > >>>>> anything, > >>>>>> I > >>>>>>>>>> have to rebuild the whole project. With maven it's fairly easy > to > >>>>> go > >>>>>> in > >>>>>>>>>> to > >>>>>>>>>> the sub module you are working on and make "local" changes > there. > >>>>> You > >>>>>>>>>> can > >>>>>>>>>> rebuild and deploy easily without having to do a whole build. > Of > >>>>>> course > >>>>>>>>>> you > >>>>>>>>>> can run a full build if you like. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Testing > >>>>>>>>>> > >>>>>>>>>> Right now we have an issue with testing. The unit tests are > also > >>>>>>>>>> monolithic. Originally, they all run or they all didn't. > >>>>>> Unfortunately, > >>>>>>>>>> it > >>>>>>>>>> took too long to run all of them, so we now have a somewhat > >>>>> arbitrary > >>>>>>>>>> distinction between long running and short running tests. Only > >> the > >>>>>> short > >>>>>>>>>> ones run by default. > >>>>>>>>>> > >>>>>>>>>> With maven, unit tests are scoped to the module which they test. > >> If > >>>>>> we > >>>>>>>>>> had > >>>>>>>>>> a Robot API module, we would have tests in that module that just > >>>>> unit > >>>>>>>>>> test > >>>>>>>>>> the Robot API. If you are working on the Robot API, you can > make > >>>>>> changes > >>>>>>>>>> and easily just run the Robot API unit tests. You can actually > >> work > >>>>>> on > >>>>>>>>>> the > >>>>>>>>>> sub module, make changes, test and check in code, without having > >> to > >>>>>> run > >>>>>>>>>> ALL > >>>>>>>>>> the unit tests for the whole project, assuming the tests are > >>>>>>>>>> comprehensive > >>>>>>>>>> for the module. The job of running all the tests can be the job > >> of > >>>>>> the > >>>>>>>>>> integration build. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Standardization > >>>>>>>>>> > >>>>>>>>>> When I was ramping up on wave, it took me over a month to become > >>>>> fully > >>>>>>>>>> comfortable with the nested ant scripts and how the project > >>>>> ultimately > >>>>>>>>>> built > >>>>>>>>>> itself. As ant projects try to become more modular, the > >> complexity > >>>>> of > >>>>>>>>>> their > >>>>>>>>>> build scripts goes exponentially up. Furthermore, each project > >> does > >>>>>> it > >>>>>>>>>> differently. You have to study the build to figure it out. > With > >>>>>> maven, > >>>>>>>>>> its > >>>>>>>>>> all pretty standard. Any developer experienced in maven can > check > >>>>> out > >>>>>>>>>> your > >>>>>>>>>> project, rigure out the module layout and how to build any > >> specific > >>>>>>>>>> module > >>>>>>>>>> they need within minutes. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Other Random Things > >>>>>>>>>> > >>>>>>>>>> Great IDE integration. > >>>>>>>>>> Dependency management. > >>>>>>>>>> A standard mechanism to deploy our artifacts for other projects > to > >>>>>> use. > >>>>>>>>>> Lot's of reports that can be generated about dependancies, > tests, > >>>>> etc. > >>>>>>>>>> Integration with SVN and standard mechanism to perform releases, > >>>>>> tagging > >>>>>>>>>> and branches. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> In my opinion maven would help us: > >>>>>>>>>> > >>>>>>>>>> Organize the project better. > >>>>>>>>>> Make our codebase more testable. > >>>>>>>>>> Shorten our development and test cycles. > >>>>>>>>>> Make our project more accessible to new developers. > >>>>>>>>>> Make our project more reusable for others. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> All of that said... it's not going to be easy to switch over, so > I > >>>>>> don't > >>>>>>>>>> take the decision lightly. > >>>>>>>>>> > >>>>>>>>>> ~Michael > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Apr 27, 2011, at 7:31 PM, Daniel Danilatos wrote: > >>>>>>>>>> > >>>>>>>>>> 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 > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Saludos, > >>>> Bruno González > >>>> > >>>> _______________________________________________ > >>>> Jabber: stenyak AT gmail.com > >>>> http://www.stenyak.com > >>>> > >> > >> > >
