Rohit, This is great work. I think technically it shows what can be done in a short amount of time. This would help scope out the work much better.
However, I would like to take a step back a little bit and actually plan this out. I will start another thread right now, where we can discuss. Thanks. ~Michael On May 1, 2011, at 4:15 AM, Rohit Rai wrote: > 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 < > michael.macfad...@gmail.com> 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 <michael.macfad...@gmail.com> >>> >>>> 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 <sten...@gmail.com> >>>> έγραψε: >>>>>> 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 <vega...@gmail.com> >>>>>> >>>>>>> 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 <michael.macfad...@gmail.com> >>>>>>> >>>>>>>> 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 <eric.char...@u-mangate.com> >>>>>>>>> >>>>>>>>>> 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< >>>>>>>>>>> michael.macfad...@gmail.com> 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 >>>>>>>>>>>>> <michael.macfad...@gmail.com> έγραψε: >>>>>>>>>>>>> >>>>>>>>>>>>>> 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 >>>>>> >>>> >>>> >> >>
