Avro
  1. Avro
  2. AVRO-146

configuration to work on Avro within Eclipse

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.3.0
    • Component/s: doc
    • Labels:
      None

      Description

      The soon-to-be-attached patch lets you work on Avro from within Eclipse, if that's your style.

      I've added the following to the README:

      USING ECLIPSE

      To use Eclipse, use the "ant eclipse" target to trigger generating a .classpath
      file, and also trigger compilation (to pull in the maven dependencies, etc.)
      You must also make sure that your avro checkout directory is "avro". You
      should then be able to create an Eclipse project pointed to your checkout, and
      run the unit tests from Eclipse's runner.

      Note that the "Eclipse Builder" is configured to compile twice: once with
      Eclipse's built-in compiler, and another time with ant. Eclipse is happier
      this way, though the classpath is configured to ignore Eclipse's compilation.

      Everything here is incomprehensible XML boilerplate. There's a new ant target to create the .classpath file.

      I'm able to run all but the interop test that requires a server from within Eclipse. I welcome other Eclipse users trying this out to see if it works.

      1. AVRO-146.patch.v3.txt
        7 kB
        Philip Zeyliger
      2. AVRO-146.patch.v2.txt
        7 kB
        Philip Zeyliger
      3. AVRO-146.patch.txt
        6 kB
        Philip Zeyliger

        Activity

        Doug Cutting made changes -
        Component/s doc [ 12313245 ]
        Doug Cutting made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Doug Cutting made changes -
        Status Patch Available [ 10002 ] Resolved [ 5 ]
        Fix Version/s 1.3.0 [ 12314318 ]
        Resolution Fixed [ 1 ]
        Hide
        Doug Cutting added a comment -

        I just committed this. Thanks, Philip!

        Show
        Doug Cutting added a comment - I just committed this. Thanks, Philip!
        Hide
        Tom White added a comment -

        I used the Eclipse configuration to successfully run the tests (except the interop tests, as noted in the README).

        Show
        Tom White added a comment - I used the Eclipse configuration to successfully run the tests (except the interop tests, as noted in the README).
        Hide
        Philip Zeyliger added a comment -

        Yes, we could probably do this for generated code, but we still need Paranamer for reflected code. For generated interfaces, in fact, we can simply include the Avro protocol as a constant and be done with it, just as we include the Avro schema in generated classes.

        I've filed AVRO-164 for this.

        Is the current version of the patch something that you feel is ready to commit? If so, can some other Eclipse user confirm that it also works for them?

        Yes, I'm ready to commit what's there. I'll ask Eli or Tom to try the Eclipse configuration to make sure it works not just for me.

        Show
        Philip Zeyliger added a comment - Yes, we could probably do this for generated code, but we still need Paranamer for reflected code. For generated interfaces, in fact, we can simply include the Avro protocol as a constant and be done with it, just as we include the Avro schema in generated classes. I've filed AVRO-164 for this. Is the current version of the patch something that you feel is ready to commit? If so, can some other Eclipse user confirm that it also works for them? Yes, I'm ready to commit what's there. I'll ask Eli or Tom to try the Eclipse configuration to make sure it works not just for me.
        Hide
        Doug Cutting added a comment -

        > If we can separate out the files that paranamer runs on [ ... ]

        I agree that this is a potential problem. Currently it does not impact build time significantly. This should be addressed as a separate issue. Ideally we could change things like this in the build without breaking Eclipse projects, e.g., if Eclipse used Ant for all compilation, but that doesn't seem acceptable to you.

        > If we're generating code, can't we just generate the parameter information and stuff it into a static field in the interface, and be done with it?

        Yes, we could probably do this for generated code, but we still need Paranamer for reflected code. For generated interfaces, in fact, we can simply include the Avro protocol as a constant and be done with it, just as we include the Avro schema in generated classes.

        Is the current version of the patch something that you feel is ready to commit? If so, can some other Eclipse user confirm that it also works for them?

        Show
        Doug Cutting added a comment - > If we can separate out the files that paranamer runs on [ ... ] I agree that this is a potential problem. Currently it does not impact build time significantly. This should be addressed as a separate issue. Ideally we could change things like this in the build without breaking Eclipse projects, e.g., if Eclipse used Ant for all compilation, but that doesn't seem acceptable to you. > If we're generating code, can't we just generate the parameter information and stuff it into a static field in the interface, and be done with it? Yes, we could probably do this for generated code, but we still need Paranamer for reflected code. For generated interfaces, in fact, we can simply include the Avro protocol as a constant and be done with it, just as we include the Avro schema in generated classes. Is the current version of the patch something that you feel is ready to commit? If so, can some other Eclipse user confirm that it also works for them?
        Hide
        Philip Zeyliger added a comment -

        Doug, I think you pin-pointed the heart of the build issue, though, and my understanding of it was wrong. Specifically:

        [Paranamer] only needs to run it on Java interfaces used as protocols, a set that intersects generated code, but is neither a proper superset nor subset.

        This is what I hadn't internalized. Currently, paranamer only runs on generated test code, because that's the only place where we use an interface as a protocol in the code base. Would you agree that we should change the build so that paranamer runs only on the set of files that we need it to run on? I'm not quite sure how to make that happen, actually, since the ParanamerGeneratorTask seems to take entire directories.

        Here's the paranamer source I was looking at:

        If we can separate out the files that paranamer runs on, then since they're already enumerated in the build, I can figure out how to make Eclipse understand them.

        How do you think it best to move forward? Write a paranamer macro that copies one file out of a tree into a parallel temporary tree, works on it, and pushes it back? Something way more clever?

        Some misgivings about paranamer

        This discussion has given me some misgivings about first generating Java code, and then running paranamer on it. If we're generating code, can't we just generate the parameter information and stuff it into a static field in the interface, and be done with it? (We can, in fact, even use their interface and add __PARANAMER_DATA, so that there's only one read path.) People with trivial build systems will want to punt, generate the code with a command-line tool once, check in the generated code as if it's their own, and be done with it. (Checking in of generated code happens a lot with Thrift, in part because Thrift has, in the past, been recalcitrant to build.) But that's not enough: they also have to run paranamer on it, at which point they're checking in .class files, and that's not nice. More advanced users will generate code from schemas at build-time. Some of those people will be doing so with Eclipse... I'm a little worried that we're imposing more hoops on those people than they deserve.

        Anyway, that's neither here nor there for Eclipse support. I think it'll get worked out as we build some tutorials of how to use Avro.

        Eclipe Questions

        You asked some specific questions about Eclipse; I've done my best to answer below. Sorry it's so wordy.

        [You] don't want Eclipse to compile everything via Ant (my first choice) [because] this would somehow disable lots of Eclipse awesomeness. Is that right?

        Yep, that's right. Part of that awesomeness is speed (calling out to ant is slower), and part of that is that Eclipse's native compiler integrates with the editor and the debugger.

        can Eclipse actually not handle multiple source trees that share a classes directory?

        The Eclipse background
        The problem is a bit more nuanced than that. It doesn't like the overlap of "sources" and "libraries". "Sources" are directories with a Java source tree, and "libraries" are either classes/ directories or jar files. The classes/ directory which comes from sources doesn't get included in the configuration--Eclipse prefers to compile to classes itself. (Eclipse is configured to build the .classes tree in .eclipse/something-or-other, and I don't want to colocate that with where ant builds it, because I want to very explicitly avoid at all costs accidentally packaging something compiled by Eclipse.)

        I think a specific example would help. Let's say we have two classes: FooProtocol.java, which is generated and compiled by ant (because it needs paranamer). It's in classes/FooProtocol.class and build/src/FooProtocol.java. And then we have SpecificCompiler.java, in classes/SpecificCompiler.class and src/SpecificCompiler.java. If I tell Eclipse that "src" is one of the package sourcs, and "classes" is one of the libraries, then, when I do a lookup for "SpecificCompiler", it will give me two things: both SpecificCompiler.java and SpecificCompiler.class, because both are available to it. It's possible to convince it that SpecificCompiler.java is "ahead of" SpecificCompiler.class, but it makes Ecilpse work worse. And if you get the classpath misconfigured, it can get confused about which one it should run. So, the best thing to do is to not tell Eclipse about SpecificCompiler.class at all. You can do this by explicitly excluding it (hard to do when there are 100 of these), or by putting it in a different directory.

        Does that make sense? Anyway, that's the problem.

        I think I can make Eclipse work with however AVRO sets up the build.

        We had Eclipse support built into Hadoop a long time ago.

        Two observations here:

        • There was and is an Eclipse plug-in for Hadoop. It suffers from lack of use and development.
        • There is an ant target called "eclipse-files". It doesn't always work, but I can tell you that it works right now in mapred and hdfs. I'm one of the people who tries to post a patch every time I run into it being broken. The most common failure is that the dependencies/ivy have changed. If the way that Avro manages that turns out to work, I will try to port that over to Hadoop as well; it'll fix the most common error. Besides that frequent but easy-to-fix problem, the Eclipse stuff has been mostly working. The JIRA process (and how Hadoop stores the Eclipse templates in a separate directory, which don't show up in "svn diff") imposes some friction on trivial fixes, so I sense that people who are using Eclipse are well-versed enough with it to just work around problems as they come.

        since they're unlikely to re-generate their project.

        I tend to regenerate frequently, but it depends on the person. It helps that "ant clean" will blow it away

        Show
        Philip Zeyliger added a comment - Doug, I think you pin-pointed the heart of the build issue, though, and my understanding of it was wrong. Specifically: [Paranamer] only needs to run it on Java interfaces used as protocols, a set that intersects generated code, but is neither a proper superset nor subset. This is what I hadn't internalized. Currently, paranamer only runs on generated test code, because that's the only place where we use an interface as a protocol in the code base. Would you agree that we should change the build so that paranamer runs only on the set of files that we need it to run on? I'm not quite sure how to make that happen, actually, since the ParanamerGeneratorTask seems to take entire directories. Here's the paranamer source I was looking at: http://www.google.com/codesearch/p?ct=rc#OCCc6t7eB3k/trunk/paranamer-ant/src/java/com/thoughtworks/paranamer/ant/ParanamerGeneratorTask.java http://www.google.com/codesearch/p?ct=rc#OCCc6t7eB3k/trunk/paranamer-generator/src/java/com/thoughtworks/paranamer/generator/QdoxParanamerGenerator.java If you have Paranamer checked out, it's just ParanamerGeneratorTask and QdoxParanamerGenerator. If we can separate out the files that paranamer runs on, then since they're already enumerated in the build, I can figure out how to make Eclipse understand them. How do you think it best to move forward? Write a paranamer macro that copies one file out of a tree into a parallel temporary tree, works on it, and pushes it back? Something way more clever? Some misgivings about paranamer This discussion has given me some misgivings about first generating Java code, and then running paranamer on it. If we're generating code, can't we just generate the parameter information and stuff it into a static field in the interface, and be done with it? (We can, in fact, even use their interface and add __PARANAMER_DATA, so that there's only one read path.) People with trivial build systems will want to punt, generate the code with a command-line tool once, check in the generated code as if it's their own, and be done with it. (Checking in of generated code happens a lot with Thrift, in part because Thrift has, in the past, been recalcitrant to build.) But that's not enough: they also have to run paranamer on it, at which point they're checking in .class files, and that's not nice. More advanced users will generate code from schemas at build-time. Some of those people will be doing so with Eclipse... I'm a little worried that we're imposing more hoops on those people than they deserve. Anyway, that's neither here nor there for Eclipse support. I think it'll get worked out as we build some tutorials of how to use Avro. Eclipe Questions You asked some specific questions about Eclipse; I've done my best to answer below. Sorry it's so wordy. [You] don't want Eclipse to compile everything via Ant (my first choice) [because] this would somehow disable lots of Eclipse awesomeness. Is that right? Yep, that's right. Part of that awesomeness is speed (calling out to ant is slower), and part of that is that Eclipse's native compiler integrates with the editor and the debugger. can Eclipse actually not handle multiple source trees that share a classes directory? The Eclipse background The problem is a bit more nuanced than that. It doesn't like the overlap of "sources" and "libraries". "Sources" are directories with a Java source tree, and "libraries" are either classes/ directories or jar files. The classes/ directory which comes from sources doesn't get included in the configuration--Eclipse prefers to compile to classes itself. (Eclipse is configured to build the .classes tree in .eclipse/something-or-other, and I don't want to colocate that with where ant builds it, because I want to very explicitly avoid at all costs accidentally packaging something compiled by Eclipse.) I think a specific example would help. Let's say we have two classes: FooProtocol.java, which is generated and compiled by ant (because it needs paranamer). It's in classes/FooProtocol.class and build/src/FooProtocol.java. And then we have SpecificCompiler.java, in classes/SpecificCompiler.class and src/SpecificCompiler.java. If I tell Eclipse that "src" is one of the package sourcs, and "classes" is one of the libraries, then, when I do a lookup for "SpecificCompiler", it will give me two things: both SpecificCompiler.java and SpecificCompiler.class, because both are available to it. It's possible to convince it that SpecificCompiler.java is "ahead of" SpecificCompiler.class, but it makes Ecilpse work worse. And if you get the classpath misconfigured, it can get confused about which one it should run. So, the best thing to do is to not tell Eclipse about SpecificCompiler.class at all. You can do this by explicitly excluding it (hard to do when there are 100 of these), or by putting it in a different directory. Does that make sense? Anyway, that's the problem. I think I can make Eclipse work with however AVRO sets up the build. We had Eclipse support built into Hadoop a long time ago. Two observations here: There was and is an Eclipse plug-in for Hadoop. It suffers from lack of use and development. There is an ant target called "eclipse-files". It doesn't always work, but I can tell you that it works right now in mapred and hdfs. I'm one of the people who tries to post a patch every time I run into it being broken. The most common failure is that the dependencies/ivy have changed. If the way that Avro manages that turns out to work, I will try to port that over to Hadoop as well; it'll fix the most common error. Besides that frequent but easy-to-fix problem, the Eclipse stuff has been mostly working. The JIRA process (and how Hadoop stores the Eclipse templates in a separate directory, which don't show up in "svn diff") imposes some friction on trivial fixes, so I sense that people who are using Eclipse are well-versed enough with it to just work around problems as they come. since they're unlikely to re-generate their project. I tend to regenerate frequently, but it depends on the person. It helps that "ant clean" will blow it away
        Hide
        Doug Cutting added a comment -

        Philip, you told me a lot about Eclipse's awesomeness, and I'll trust you on that. Viva Eclipse!

        I think you may have answered one of my questions: the reason why you don't want Eclipse to compile everything via Ant (my first choice) is that this would somehow disable lots of Eclipse awesomeness. Is that right? Eclipse doesn't just need to know where the sources and classes are, it needs to generate the .class files itself in order to be most awesome?

        I don't think you answered my other implicit question, so I'll make it explicit: can Eclipse actually not handle multiple source trees that share a classes directory? You seemed to motivate this change with the assertion that Avro only needs to run paranamer on generated code, but that's not true. It only needs to run it on Java interfaces used as protocols, a set that intersects generated code, but is neither a proper superset nor subset. Your statements make it clear that you dislike this sharing, but not whether this is mandated by Eclipse. Is it actually?

        We had Eclipse support built into Hadoop a long time ago. It compiled, but wasn't maintained. Nice, innocent folks would try to use it in releases and it would fail. I want to avoid that. Making this as simple as possible without losing intense awesomeness is my goal here.

        Show
        Doug Cutting added a comment - Philip, you told me a lot about Eclipse's awesomeness, and I'll trust you on that. Viva Eclipse! I think you may have answered one of my questions: the reason why you don't want Eclipse to compile everything via Ant (my first choice) is that this would somehow disable lots of Eclipse awesomeness. Is that right? Eclipse doesn't just need to know where the sources and classes are, it needs to generate the .class files itself in order to be most awesome? I don't think you answered my other implicit question, so I'll make it explicit: can Eclipse actually not handle multiple source trees that share a classes directory? You seemed to motivate this change with the assertion that Avro only needs to run paranamer on generated code, but that's not true. It only needs to run it on Java interfaces used as protocols, a set that intersects generated code, but is neither a proper superset nor subset. Your statements make it clear that you dislike this sharing, but not whether this is mandated by Eclipse. Is it actually? We had Eclipse support built into Hadoop a long time ago. It compiled, but wasn't maintained. Nice, innocent folks would try to use it in releases and it would fail. I want to avoid that. Making this as simple as possible without losing intense awesomeness is my goal here.
        Hide
        Philip Zeyliger added a comment -

        Doug,

        I think you're being overly conservative here. Eclipse, once you get past the learning curve and configuration, is a powerful tool for code exploration and debugging, and requires relatively few concessions. It has a deep understanding of Java, so it works best (and is least flakey) when it is the compiler. Its configuration is roughly made up of two things: (1) what are all the source files? These Eclipse lets you edit, and it builds them for you. Because it "understands" them, it builds them continually (if you so choose) and incrementally. (2) What are the libraries? These are jars or directories of .class files, and it puts them on the classpath.

        The concessions that Eclipse requires are that you separate out the sources files from the libraries. In Avro's case (and in other systems that use some generated-code), this means considering generated code as a library, but considering the source stuff as source. So, I've had to separate the classes/ directory for the generated code away from the classes/ directory for the rest of the test code. That in itself is probably for the better: collapsing multiple source trees (src/test/java and build/test/src, I think) into one classes/ tree feels icky to me in itself.

        I totally understand that you don't wish the maintenance hassle of Eclipse. The ant-eclipse task makes it pretty minor: you certainly don't have to update the classpath file every time a dependency changes, and that's a win. Every time you make a structural change--adding new source directories in one way or another, you'll have to enlist an Eclipse user to help you edit that configuration. How often, in Java, should that be happening? In its ideal, Java is dead simple: source trees layed out as packages, and jar files. If having Eclipse in there makes a push to have the build be simpler, that's a good thing I could probably rig up a system that runs Eclipse in headless mode and tests that the configuration worked, but it's probably more hassle than it's worth right now.

        BTW, I used the Eclipse stuff for several hours yesterday, and it worked well for working with Avro. When I ran into something I didn't understand in the code base, I double-clicked in the margins to set a breakpoint, clicked the "Debug AllTests" button, and, one second later, I was staring at how the method I was trying to understand was called, by which test, and with what parameters. It's a tool, it's not perfect, but it'd good enough that I make concessions to it.

        You should give it a chance in the build file.

        Show
        Philip Zeyliger added a comment - Doug, I think you're being overly conservative here. Eclipse, once you get past the learning curve and configuration, is a powerful tool for code exploration and debugging, and requires relatively few concessions. It has a deep understanding of Java, so it works best (and is least flakey) when it is the compiler. Its configuration is roughly made up of two things: (1) what are all the source files? These Eclipse lets you edit, and it builds them for you. Because it "understands" them, it builds them continually (if you so choose) and incrementally. (2) What are the libraries? These are jars or directories of .class files, and it puts them on the classpath. The concessions that Eclipse requires are that you separate out the sources files from the libraries. In Avro's case (and in other systems that use some generated-code), this means considering generated code as a library, but considering the source stuff as source. So, I've had to separate the classes/ directory for the generated code away from the classes/ directory for the rest of the test code. That in itself is probably for the better: collapsing multiple source trees (src/test/java and build/test/src, I think) into one classes/ tree feels icky to me in itself. I totally understand that you don't wish the maintenance hassle of Eclipse. The ant-eclipse task makes it pretty minor: you certainly don't have to update the classpath file every time a dependency changes, and that's a win. Every time you make a structural change--adding new source directories in one way or another, you'll have to enlist an Eclipse user to help you edit that configuration. How often, in Java, should that be happening? In its ideal, Java is dead simple: source trees layed out as packages, and jar files. If having Eclipse in there makes a push to have the build be simpler, that's a good thing I could probably rig up a system that runs Eclipse in headless mode and tests that the configuration worked, but it's probably more hassle than it's worth right now. BTW, I used the Eclipse stuff for several hours yesterday, and it worked well for working with Avro. When I ran into something I didn't understand in the code base, I double-clicked in the margins to set a breakpoint, clicked the "Debug AllTests" button, and, one second later, I was staring at how the method I was trying to understand was called, by which test, and with what parameters. It's a tool, it's not perfect, but it'd good enough that I make concessions to it. You should give it a chance in the build file.
        Hide
        Doug Cutting added a comment -

        > The only things that Avro tests absolutely need paranamer to run on are the classes generated from the schemas.

        We actually only need to run paranamer on protocol interfaces, not schemas, to find message parameter names. So we could change the ant task to accept a list of protocol interface names, or perhaps use .avpr files to identify classes (although those don't exist when reflection's used). Shuffling generated code to a different directory seems like a halfway fix. Why bother?

        Also, I'm uncomfortable building much knowledge of Avro's build into this, since it may have to be updated whenever Avro's build changes, which non-Eclipse users will be unable to test. Even Eclipse users will probably not test this frequently, since they're unlikely to re-generate their project. I don't want to make a release and then later discover that 'ant eclipse' generates an unbuildable project.

        The simplest approach is to configure Eclipse to call just back to Ant for all compilation. That's ideal from a maintenance perspective. Since we have to do that anyway for paranamer, why use Eclipse for any compilation? (As a non-Eclipse user I am a natural devil's advocate here.)

        Show
        Doug Cutting added a comment - > The only things that Avro tests absolutely need paranamer to run on are the classes generated from the schemas. We actually only need to run paranamer on protocol interfaces, not schemas, to find message parameter names. So we could change the ant task to accept a list of protocol interface names, or perhaps use .avpr files to identify classes (although those don't exist when reflection's used). Shuffling generated code to a different directory seems like a halfway fix. Why bother? Also, I'm uncomfortable building much knowledge of Avro's build into this, since it may have to be updated whenever Avro's build changes, which non-Eclipse users will be unable to test. Even Eclipse users will probably not test this frequently, since they're unlikely to re-generate their project. I don't want to make a release and then later discover that 'ant eclipse' generates an unbuildable project. The simplest approach is to configure Eclipse to call just back to Ant for all compilation. That's ideal from a maintenance perspective. Since we have to do that anyway for paranamer, why use Eclipse for any compilation? (As a non-Eclipse user I am a natural devil's advocate here.)
        Hide
        Philip Zeyliger added a comment -

        I couldn't resist and checked out bixo. They've packaged ant-eclipse into a Maven repository at http://oss.101tec.com/nexus/content/groups/public/ant-eclipse/ant-eclipse-jvm1.2/ . I don't know how one gets things into "official" ivy repositories. For now, I've copied your method, and it gets the job done.

        Show
        Philip Zeyliger added a comment - I couldn't resist and checked out bixo. They've packaged ant-eclipse into a Maven repository at http://oss.101tec.com/nexus/content/groups/public/ant-eclipse/ant-eclipse-jvm1.2/ . I don't know how one gets things into "official" ivy repositories. For now, I've copied your method, and it gets the job done.
        Hide
        Patrick Hunt added a comment -

        Philip, donno about clever, afaict ant-eclipse is not deployed to any maven repository. So the next best thing
        I could think of was to pull it manually (which I basically coped from the way the ivy jar is d/l as part
        of the build bootstrapping). Perhaps if the ivy docs were more understandable, or maybe it's just that I'm
        not smart enough to understand them, I might have figured out a better way.

        Show
        Patrick Hunt added a comment - Philip, donno about clever, afaict ant-eclipse is not deployed to any maven repository. So the next best thing I could think of was to pull it manually (which I basically coped from the way the ivy jar is d/l as part of the build bootstrapping). Perhaps if the ivy docs were more understandable, or maybe it's just that I'm not smart enough to understand them, I might have figured out a better way.
        Philip Zeyliger made changes -
        Attachment AVRO-146.patch.v3.txt [ 12422297 ]
        Hide
        Philip Zeyliger added a comment -

        Another quick fix. The settings files that ant-eclipse was generating because of the <settings> flag were making the Eclipse editor unhappy (it was doing type erasure of some sort). I've deleted the settings, and things are better. (I'm actually trying to write some code, so this Eclipse stuff may keep coming...)

        Show
        Philip Zeyliger added a comment - Another quick fix. The settings files that ant-eclipse was generating because of the <settings> flag were making the Eclipse editor unhappy (it was doing type erasure of some sort). I've deleted the settings, and things are better. (I'm actually trying to write some code, so this Eclipse stuff may keep coming...)
        Philip Zeyliger made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Philip Zeyliger made changes -
        Attachment AVRO-146.patch.v2.txt [ 12422287 ]
        Hide
        Philip Zeyliger added a comment -

        Patrick,

        Thanks for the reference. I'm uploading a new patch, which:

        1. Works. (I dropped the .project file in the previous patch, so, had you tried it, it wouldn't have worked :/)
        2. Uses ant-eclipse. For simple things, ant-eclipse seems to work well. The bixo project (see http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#hMNiHrMJ4Bc/ivy.xml&q=ivy.xml%20ant-eclipse&l=44 ) manages to pull in ant-eclipse via Ivy, but I haven't been able to figure out how they do it. So, I followed zookeepers approach and pull it in manually. Patrick — any clever thoughts here?
        3. Changes build.xml to separate out build/test/classes and build/test/generated/classes. The only things that Avro tests absolutely need paranamer to run on are the classes generated from the schemas. By having two distinct classpaths in there, it's easier to configure eclipse to compile the tests themselves, but to rely on ant to build the generated code. That's a mouthful: I think, in general, it's reasonable to have one "classes" directory per "src" directory, and this makes this true.
        4. Seems to be snappier, because Eclipse no longer calls ant; you only need to call it when you change code that needs to get generated.

        If someone here uses Eclipse, would be great to have someone else try it.

        – Philip

        Show
        Philip Zeyliger added a comment - Patrick, Thanks for the reference. I'm uploading a new patch, which: Works. (I dropped the .project file in the previous patch, so, had you tried it, it wouldn't have worked :/) Uses ant-eclipse. For simple things, ant-eclipse seems to work well. The bixo project (see http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#hMNiHrMJ4Bc/ivy.xml&q=ivy.xml%20ant-eclipse&l=44 ) manages to pull in ant-eclipse via Ivy, but I haven't been able to figure out how they do it. So, I followed zookeepers approach and pull it in manually. Patrick — any clever thoughts here? Changes build.xml to separate out build/test/classes and build/test/generated/classes. The only things that Avro tests absolutely need paranamer to run on are the classes generated from the schemas. By having two distinct classpaths in there, it's easier to configure eclipse to compile the tests themselves, but to rely on ant to build the generated code. That's a mouthful: I think, in general, it's reasonable to have one "classes" directory per "src" directory, and this makes this true. Seems to be snappier, because Eclipse no longer calls ant; you only need to call it when you change code that needs to get generated. If someone here uses Eclipse, would be great to have someone else try it. – Philip
        Hide
        Patrick Hunt added a comment -

        fyi, not sure what approach is better but we recently added eclipse support to zookeeper in ZOOKEEPER-539 via

        http://sourceforge.net/projects/ant-eclipse/

        Show
        Patrick Hunt added a comment - fyi, not sure what approach is better but we recently added eclipse support to zookeeper in ZOOKEEPER-539 via http://sourceforge.net/projects/ant-eclipse/
        Philip Zeyliger made changes -
        Field Original Value New Value
        Attachment AVRO-146.patch.txt [ 12422041 ]
        Philip Zeyliger created issue -

          People

          • Assignee:
            Philip Zeyliger
            Reporter:
            Philip Zeyliger
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development