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 >>>> >> >>
