+1 from me too; this discussion happened on the google group as well. Without people actually committing to work on it it's a pointless discussion.
On Sun, May 1, 2011 at 12:44 AM, Yuri Z <[email protected]> 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 > > >> > > > > >
