Re: Yet another eclipse problem, was: svn commit: r440909...
Well, even the most fanatical VI user I know has moved to using an Eclipse VI plugin now, so I really can't imagine very many (other than people that also spend their weekends carving wheels out of stone :-) really using it these days. As far as Emacs is concerned, I must admit that I myself still use it when I'm doing bulk editing (my fingers just automatically hit those ctrl keys), but it's not my IDE (it's just an editor). I know that Emacs is still used as a Java IDE by a few people, but not very many. I'm sure we could discuss the pros and cons of various tools indefinitely, but the bottom line is that Eclipse is used by LOTS of people, not just a few. Jeremy may not want to alienate non-Eclipse users, but avoiding that by alienating the large (Eclipse users) group doesn't make sense either. Jim, you said this: If we find that Maven consistently causes problems for a wide variety of developers, then we should change to something better. But more sensible would be to say causes problems for a large percentage of developers, which is the case. I don't know exactly how to handle this, but just saying all you crazy Eclipse users are on your own, isn't going to help. I don't think Jeremy's portrayal of Eclipse as some piece of junk with an ongoing stream of problems is really the case either, it just seems to me that the bottom line is that Eclipse has a few problems integrating with Maven that need to be addressed. I'm sure both the Eclipse and Maven communities have a vested interest in seeing that happen. Frank Jim Marino [EMAIL PROTECTED] wrote on 09/07/2006 10:02:35 AM: On Sep 7, 2006, at 6:03 AM, ant elder wrote: I completely agree with Frank. Also whether or not it is possible to get free copies of IDEA is beside the point, a lot of people use Eclipse so we need to embrace that if we want to encourage them to contribute to Tuscany. And a lot of people use IDEA, Emacs, VI, etc. For example, most of the developers I know use IDEA and Emacs, not Eclipse (even though the Eclipse juggernaut has significantly more market share) . The point is twofold. We need to accommodate as many as possible, not just Eclipse users. The second is checking in unverifiable artifacts is bound to lead to a break at some point. ...ant On 9/7/06, Frank Budinsky [EMAIL PROTECTED] wrote: I would say that thinking about Eclipse as just one of a many IDEs that people may be using is totally off the mark. In reality, there are only a very few popular Java IDEs (two, actually), and Eclipse is the free one. So, in my opinion, not accommodating Eclipse seems ludicrous - it will inconvenience a lot of people. I would think that the more productive route would be to say that we officially support Eclipse and that we file Eclipse bug reports and/or create (temporary) workarounds to make sure that it works. Saying that people have an alternative (simply shelling out $500 for IDEA) doesn't sound very convincing to me either. I'm sorry but I believe thinking about Eclipse as just one of the many IDEs is completely valid. We need to be as open as possible, particularly since there is no good reason in my mind why we should anoint a particular IDE for Tuscany developers (and that goes for IDEA too). For me, the question is not about accommodating Eclipse but having a build process that works with the tool we chose, Maven, and making it easy for developers using a variety of tooling environments. Otherwise, we should use Eclipse to do the build and mandate that it is run prior to checkin ;-) The need to accommodate a variety of development environments is a balancing act. In the specific case that prompted Jeremy's rant, a problem in Eclipse resulted in the introduction of a change to the build process that makes working with Maven, particularly for distributions, extremely difficult. I think we should err on the side of Maven. Another example would be a hypothetical bug in, say, the IDEA compiler. If it only occurs in one place, maybe we could put a work-around in the code as long as it did not impact performance or cause drastic changes for others. If it required something like a performance hit or not using an important language feature, IDEA users would need to accommodate. If we find that Maven consistently causes problems for a wide variety of developers, then we should change to something better. Jim Frank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet another eclipse problem, was: svn commit: r440909...
On Sep 8, 2006, at 6:19 AM, Frank Budinsky wrote: Well, even the most fanatical VI user I know has moved to using an Eclipse VI plugin now, so I really can't imagine very many (other than people that also spend their weekends carving wheels out of stone :-) really using it these days. As far as Emacs is concerned, I must admit that I myself still use it when I'm doing bulk editing (my fingers just automatically hit those ctrl keys), but it's not my IDE (it's just an editor). I know that Emacs is still used as a Java IDE by a few people, but not very many. I'm sure we could discuss the pros and cons of various tools indefinitely, but the bottom line is that Eclipse is used by LOTS of people, not just a few. Jeremy may not want to alienate non-Eclipse users, but avoiding that by alienating the large (Eclipse users) group doesn't make sense either. Jim, you said this: If we find that Maven consistently causes problems for a wide variety of developers, then we should change to something better. But more sensible would be to say causes problems for a large percentage of developers, which is the case. I don't know exactly how to handle this, but just saying all you crazy Eclipse users are on your own, isn't going to help. I don't think Jeremy's portrayal of Eclipse as some piece of junk with an ongoing stream of problems is really the case either, it just seems to me that the bottom line is that Eclipse has a few problems integrating with Maven that need to be addressed. I'm sure both the Eclipse and Maven communities have a vested interest in seeing that happen. I guess I touched a nerve here and I will turn down the Eclipse teasing (well at least a little). I do think Eclipse has issues coping with Maven project structures - the two tools have different ideas on how things should be arranged, each wanting to do things its own way. I'm sure the Maven and Eclipse communities will address the differences over time but until that happens we need to make our own accommodations. As a project we needed to pick a primary and we chose Maven as the build system. We can re-examine that decision but I think that should be a separate discussion. This leaves us with a recurring problem in that someone making changes to the Maven build has no easy way to validate that they won't break someone else's IDE setup (irrespective of which IDE it is). I'm really looking for a solution for this that does not involve installing any particular IDE. One solution is to check in IDE-specific artifacts on the understanding they are not normative. However, I share Jim's concern that people stop running the project's Maven build and only use the IDE (for example, someone recently told me the build was broken because it failed in Eclipse although it worked fine with Maven). Alternatively the same artifacts could be checked into another location. I know that would work for IDEA, I don't know if Eclipse supports such a setup. We still need to ensure developers run the main build. Another common approach in open source projects is just to say everyone is responsible for their own IDE setup. We won't deliberately try to break things, but the common ground is our project build (Maven) and IDE users have to adapt. All of these have their downsides so if anyone has another alternative please speak up (but please don't tell me to install Eclipse). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet another eclipse problem, was: svn commit: r440909...
On Sep 8, 2006, at 6:19 AM, Frank Budinsky wrote: Well, even the most fanatical VI user I know has moved to using an Eclipse VI plugin now, so I really can't imagine very many (other than people that also spend their weekends carving wheels out of stone :-) really using it these days. Strange enough a good friend of mine (an architect at Macromedia/ Adobe) still uses it because he says VI is burned into his brain. The point is, we need to accommodate a heterogeneous development community. For example, if you took a poll of the people involved in the Java SCA project, I think you will find at least 6 of us who use IDEA. This is of course a balancing act but it is something we should be aware of. As far as Emacs is concerned, I must admit that I myself still use it when I'm doing bulk editing (my fingers just automatically hit those ctrl keys), but it's not my IDE (it's just an editor). I know that Emacs is still used as a Java IDE by a few people, but not very many. I'm sure we could discuss the pros and cons of various tools indefinitely, but the bottom line is that Eclipse is used by LOTS of people, not just a few. Jeremy may not want to alienate non-Eclipse users, but avoiding that by alienating the large (Eclipse users) group doesn't make sense either. I don't think this is a discussion of the pros and cons of Eclipse or another IDE. It's about how to deal with all of the hidden requirements Eclipse seems to be placing on our build process, and from what Jeremy says, these requirements cause serious problems with Maven. Jim, you said this: If we find that Maven consistently causes problems for a wide variety of developers, then we should change to something better. But more sensible would be to say causes problems for a large percentage of developers, which is the case. Then could you propose an alternative? One of the groups at BEA threw out Maven and created their own build system using rsync. Should we do the same? I don't know exactly how to handle this, but just saying all you crazy Eclipse users are on your own, isn't going to help. I don't think Jeremy's portrayal of Eclipse as some piece of junk with an ongoing stream of problems is really the case either, I didn't read Jeremy's portrayal of Eclipse as that of a piece of junk. FWIW, I think it's not bad but it isn't great either. I was a fairly long-time user (before 2.0) but switched because I was running into problems and, more importantly, IDEA was better for me. I did the same thing before with other Java IDEs, moving from TextPad to Visual Cafe to JBuilder. it just seems to me that the bottom line is that Eclipse has a few problems integrating with Maven that need to be addressed. I'm sure both the Eclipse and Maven communities have a vested interest in seeing that happen. We should definitely do that. Has anyone filed a bug with Eclipse on this? In the meantime, I don't think we should bork our build system because of this (assuming this is a real problem, which Jeremy says it is). Perhaps the easiest solution is to do one of the following: 1. Suggest an alternative to Maven 2. Place workaround instructions on the sire for Eclipse users where the getting started instructions are. Eclipse artifacts such as .project could be there for download as well. I don't like the idea of these going directly into the trunk as they are bound to become out of sync. Jim Frank Jim Marino [EMAIL PROTECTED] wrote on 09/07/2006 10:02:35 AM: On Sep 7, 2006, at 6:03 AM, ant elder wrote: I completely agree with Frank. Also whether or not it is possible to get free copies of IDEA is beside the point, a lot of people use Eclipse so we need to embrace that if we want to encourage them to contribute to Tuscany. And a lot of people use IDEA, Emacs, VI, etc. For example, most of the developers I know use IDEA and Emacs, not Eclipse (even though the Eclipse juggernaut has significantly more market share) . The point is twofold. We need to accommodate as many as possible, not just Eclipse users. The second is checking in unverifiable artifacts is bound to lead to a break at some point. ...ant On 9/7/06, Frank Budinsky [EMAIL PROTECTED] wrote: I would say that thinking about Eclipse as just one of a many IDEs that people may be using is totally off the mark. In reality, there are only a very few popular Java IDEs (two, actually), and Eclipse is the free one. So, in my opinion, not accommodating Eclipse seems ludicrous - it will inconvenience a lot of people. I would think that the more productive route would be to say that we officially support Eclipse and that we file Eclipse bug reports and/or create (temporary) workarounds to make sure that it works. Saying that people have an alternative (simply shelling out $500 for IDEA) doesn't sound very convincing to me either. I'm sorry but I believe thinking about Eclipse as just one of the many IDEs is
Re: Yet another eclipse problem, was: svn commit: r440909...
Hi, I'm a loyal Eclipse user (never have a chance to try IDEA) and let me try to be constructive here. What are issues here due to the conflict of maven and Eclipse? I observed two: a) Cannot use the root folder to host NOTICE, LICENSE and other files b) Cannot automatically replace a maven property in resource files such as SCDL Issue a) is due to a limitation in maven-eclipse-plugin and it's not an Eclipse problem. Eclipse does support overlapping source folders with inclusion and exclusion patterns. Solution: Open a JIRA against the maven-eclipse-plugin to get it fixed. I read the source code, it's fairly simple. If time permits, we can provide a patch. Issue b): The purpose is to make it easy to keep the namespace synchronized with the Tuscany version. I don't think the maven-filtering is a complete solution because we still hard-code the namespaces in the loaders anyway. Solution: Hard-code the namespace in SCDL files for now and use the powerful IDE replace function to change all the occurences when we're ready to move up to a newer Tuscany version. :-) Any other issues? Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, September 08, 2006 8:51 AM Subject: Re: Yet another eclipse problem, was: svn commit: r440909... On Sep 8, 2006, at 6:19 AM, Frank Budinsky wrote: Well, even the most fanatical VI user I know has moved to using an Eclipse VI plugin now, so I really can't imagine very many (other than people that also spend their weekends carving wheels out of stone :-) really using it these days. Strange enough a good friend of mine (an architect at Macromedia/ Adobe) still uses it because he says VI is burned into his brain. The point is, we need to accommodate a heterogeneous development community. For example, if you took a poll of the people involved in the Java SCA project, I think you will find at least 6 of us who use IDEA. This is of course a balancing act but it is something we should be aware of. As far as Emacs is concerned, I must admit that I myself still use it when I'm doing bulk editing (my fingers just automatically hit those ctrl keys), but it's not my IDE (it's just an editor). I know that Emacs is still used as a Java IDE by a few people, but not very many. I'm sure we could discuss the pros and cons of various tools indefinitely, but the bottom line is that Eclipse is used by LOTS of people, not just a few. Jeremy may not want to alienate non-Eclipse users, but avoiding that by alienating the large (Eclipse users) group doesn't make sense either. I don't think this is a discussion of the pros and cons of Eclipse or another IDE. It's about how to deal with all of the hidden requirements Eclipse seems to be placing on our build process, and from what Jeremy says, these requirements cause serious problems with Maven. Jim, you said this: If we find that Maven consistently causes problems for a wide variety of developers, then we should change to something better. But more sensible would be to say causes problems for a large percentage of developers, which is the case. Then could you propose an alternative? One of the groups at BEA threw out Maven and created their own build system using rsync. Should we do the same? I don't know exactly how to handle this, but just saying all you crazy Eclipse users are on your own, isn't going to help. I don't think Jeremy's portrayal of Eclipse as some piece of junk with an ongoing stream of problems is really the case either, I didn't read Jeremy's portrayal of Eclipse as that of a piece of junk. FWIW, I think it's not bad but it isn't great either. I was a fairly long-time user (before 2.0) but switched because I was running into problems and, more importantly, IDEA was better for me. I did the same thing before with other Java IDEs, moving from TextPad to Visual Cafe to JBuilder. it just seems to me that the bottom line is that Eclipse has a few problems integrating with Maven that need to be addressed. I'm sure both the Eclipse and Maven communities have a vested interest in seeing that happen. We should definitely do that. Has anyone filed a bug with Eclipse on this? In the meantime, I don't think we should bork our build system because of this (assuming this is a real problem, which Jeremy says it is). Perhaps the easiest solution is to do one of the following: 1. Suggest an alternative to Maven 2. Place workaround instructions on the sire for Eclipse users where the getting started instructions are. Eclipse artifacts such as .project could be there for download as well. I don't like the idea of these going directly into the trunk as they are bound to become out of sync. Jim Frank Jim Marino [EMAIL PROTECTED] wrote on 09/07/2006 10:02:35 AM: On Sep 7, 2006, at 6:03 AM, ant elder wrote: I completely agree with Frank. Also whether
Re: Yet another eclipse problem, was: svn commit: r440909...
On Sep 8, 2006, at 9:28 AM, Raymond Feng wrote: Hi, I'm a loyal Eclipse user (never have a chance to try IDEA) and let me try to be constructive here. Thanks - I appreciate the constructive comments :-) What are issues here due to the conflict of maven and Eclipse? I observed two: a) Cannot use the root folder to host NOTICE, LICENSE and other files b) Cannot automatically replace a maven property in resource files such as SCDL Issue a) is due to a limitation in maven-eclipse-plugin and it's not an Eclipse problem. Eclipse does support overlapping source folders with inclusion and exclusion patterns. Solution: Open a JIRA against the maven-eclipse-plugin to get it fixed. I read the source code, it's fairly simple. If time permits, we can provide a patch. I think this is the ideal solution but requires someone to maintain the plugin. We still have the lag factor where some change gets made in the build that the plugin can't handle. People can always fine- tune the IDE setup once generated (I do that with IDEA for example) and so the question becomes is it worth checking in the generated artifacts to help people along (or is it even practical e.g. if they contain absolute paths there may be problems). Issue b): The purpose is to make it easy to keep the namespace synchronized with the Tuscany version. I don't think the maven- filtering is a complete solution because we still hard-code the namespaces in the loaders anyway. Solution: Hard-code the namespace in SCDL files for now and use the powerful IDE replace function to change all the occurences when we're ready to move up to a newer Tuscany version. :-) I am very wary of global replace approaches as they so often go awry which is why I was looking at a substitution approach in the first place :-) At some point we will need to support multiple schema versions in the loaders and so may need to cherry-pick which ones get fixed. We may also have different versions in different extensions, again requiring a selective approach. Also this is only one value that is being substituted. We do perform substitution in other places but so far that is mainly for documentation (e.g. in the NOTICE files). The replace approach will not scale as we increase the number of variables. Any other issues? This is what is troubling me - I don't know. It means any change that I (the de-facto build monkey) make has the potential to break an Eclipse setup that I know nothing about. I'm not very comfortable with that. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet another eclipse problem, was: svn commit: r440909...
I would say that thinking about Eclipse as just one of a many IDEs that people may be using is totally off the mark. In reality, there are only a very few popular Java IDEs (two, actually), and Eclipse is the free one. So, in my opinion, not accommodating Eclipse seems ludicrous - it will inconvenience a lot of people. I would think that the more productive route would be to say that we officially support Eclipse and that we file Eclipse bug reports and/or create (temporary) workarounds to make sure that it works. Saying that people have an alternative (simply shelling out $500 for IDEA) doesn't sound very convincing to me either. Frank. Jim Marino [EMAIL PROTECTED] wrote on 09/07/2006 01:08:49 AM: I think this is asking for trouble for several reasons. We really should have one definitive source for the build. These artifacts are bound to break and there is no realistic way to verify that they work short of loading them in the tool they were intended for. There is still only one definitive build - the Maven one. All the others are just (unverifiable) artifacts that may work for some developers. The compensating factor here is that presumably some active developers are using them and will keep them current and working. I'm not sure it's definitive anymore due to all of the hidden requirements you mentioned below...Hoping people keep artifacts up to date is what I don't like as they will invariably break since they are not verifiable. Alternatively, if we want to keep the policy of no-IDE-specific artifacts at all, then we should bite the bullet on workarounds and say that the Maven build is definitive and that IDE setup is the responsibility of each developer - i.e. they need to set their IDE to work with the environment as defined by the Maven build. I prefer the current policy of having Maven categorically determine the state of the build. My opinion is we should not allow checkins of unverifiable artifacts. The problem is that we have requirements on checked in artifacts (the Maven POM's) that are not verifiable using the Maven build - requirements such as we can't use Maven's resource filtering because Eclipse also copies resources and does not filter them, or Eclipse cannot support the resource paths that Maven uses. There may be others (for example, I don't know how or if Eclipse recognizes code generated as part of the Maven build). That to me just seems wrong. We chose Maven to be our build system and we should use its features. If a particular IDE can't handle a basic thing thing such as resource filtering we shouldn't be restricted by that limitation as long as there are reasonable alternatives (and there are, e.g. IntelliJ; I switched exactly because of these types of issues :-) ). Besides, checkins have to be run through the mvn command line build process, not through an IDE. Jim This means people can make improvements to the build or project layout that are fine with Maven and the definitive build but which, for some reason, make Eclipse unhappy. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet another eclipse problem, was: svn commit: r440909...
I completely agree with Frank. Also whether or not it is possible to get free copies of IDEA is beside the point, a lot of people use Eclipse so we need to embrace that if we want to encourage them to contribute to Tuscany. ...ant On 9/7/06, Frank Budinsky [EMAIL PROTECTED] wrote: I would say that thinking about Eclipse as just one of a many IDEs that people may be using is totally off the mark. In reality, there are only a very few popular Java IDEs (two, actually), and Eclipse is the free one. So, in my opinion, not accommodating Eclipse seems ludicrous - it will inconvenience a lot of people. I would think that the more productive route would be to say that we officially support Eclipse and that we file Eclipse bug reports and/or create (temporary) workarounds to make sure that it works. Saying that people have an alternative (simply shelling out $500 for IDEA) doesn't sound very convincing to me either. Frank. Jim Marino [EMAIL PROTECTED] wrote on 09/07/2006 01:08:49 AM: I think this is asking for trouble for several reasons. We really should have one definitive source for the build. These artifacts are bound to break and there is no realistic way to verify that they work short of loading them in the tool they were intended for. There is still only one definitive build - the Maven one. All the others are just (unverifiable) artifacts that may work for some developers. The compensating factor here is that presumably some active developers are using them and will keep them current and working. I'm not sure it's definitive anymore due to all of the hidden requirements you mentioned below...Hoping people keep artifacts up to date is what I don't like as they will invariably break since they are not verifiable. Alternatively, if we want to keep the policy of no-IDE-specific artifacts at all, then we should bite the bullet on workarounds and say that the Maven build is definitive and that IDE setup is the responsibility of each developer - i.e. they need to set their IDE to work with the environment as defined by the Maven build. I prefer the current policy of having Maven categorically determine the state of the build. My opinion is we should not allow checkins of unverifiable artifacts. The problem is that we have requirements on checked in artifacts (the Maven POM's) that are not verifiable using the Maven build - requirements such as we can't use Maven's resource filtering because Eclipse also copies resources and does not filter them, or Eclipse cannot support the resource paths that Maven uses. There may be others (for example, I don't know how or if Eclipse recognizes code generated as part of the Maven build). That to me just seems wrong. We chose Maven to be our build system and we should use its features. If a particular IDE can't handle a basic thing thing such as resource filtering we shouldn't be restricted by that limitation as long as there are reasonable alternatives (and there are, e.g. IntelliJ; I switched exactly because of these types of issues :-) ). Besides, checkins have to be run through the mvn command line build process, not through an IDE. Jim This means people can make improvements to the build or project layout that are fine with Maven and the definitive build but which, for some reason, make Eclipse unhappy. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet another eclipse problem, was: svn commit: r440909...
By embracing Eclipse we alienate everyone else who does not use it - forcing people to install, learn, and now bugfix Eclipse if they want to contribute to Tuscany is not very open. Please bear in mind I am not advocating people use IDEA either - I want to make sure that the project is open to everyone irrespective of which IDE they prefer to use. What I would like to solve is the problem we have with Eclipse not being able to cope with project structures that make sense from a Maven perspective given that Maven is our definitive build. I would like some suggestion from the Eclipse users on how non-Eclipse users can accommodate Eclipse's problems on an ongoing basis - and being told install Eclipse and bugfix it is, to use Frank's word, ludicrous. -- Jeremy On Sep 7, 2006, at 6:03 AM, ant elder wrote: I completely agree with Frank. Also whether or not it is possible to get free copies of IDEA is beside the point, a lot of people use Eclipse so we need to embrace that if we want to encourage them to contribute to Tuscany. ...ant On 9/7/06, Frank Budinsky [EMAIL PROTECTED] wrote: I would say that thinking about Eclipse as just one of a many IDEs that people may be using is totally off the mark. In reality, there are only a very few popular Java IDEs (two, actually), and Eclipse is the free one. So, in my opinion, not accommodating Eclipse seems ludicrous - it will inconvenience a lot of people. I would think that the more productive route would be to say that we officially support Eclipse and that we file Eclipse bug reports and/or create (temporary) workarounds to make sure that it works. Saying that people have an alternative (simply shelling out $500 for IDEA) doesn't sound very convincing to me either. Frank. Jim Marino [EMAIL PROTECTED] wrote on 09/07/2006 01:08:49 AM: I think this is asking for trouble for several reasons. We really should have one definitive source for the build. These artifacts are bound to break and there is no realistic way to verify that they work short of loading them in the tool they were intended for. There is still only one definitive build - the Maven one. All the others are just (unverifiable) artifacts that may work for some developers. The compensating factor here is that presumably some active developers are using them and will keep them current and working. I'm not sure it's definitive anymore due to all of the hidden requirements you mentioned below...Hoping people keep artifacts up to date is what I don't like as they will invariably break since they are not verifiable. Alternatively, if we want to keep the policy of no-IDE-specific artifacts at all, then we should bite the bullet on workarounds and say that the Maven build is definitive and that IDE setup is the responsibility of each developer - i.e. they need to set their IDE to work with the environment as defined by the Maven build. I prefer the current policy of having Maven categorically determine the state of the build. My opinion is we should not allow checkins of unverifiable artifacts. The problem is that we have requirements on checked in artifacts (the Maven POM's) that are not verifiable using the Maven build - requirements such as we can't use Maven's resource filtering because Eclipse also copies resources and does not filter them, or Eclipse cannot support the resource paths that Maven uses. There may be others (for example, I don't know how or if Eclipse recognizes code generated as part of the Maven build). That to me just seems wrong. We chose Maven to be our build system and we should use its features. If a particular IDE can't handle a basic thing thing such as resource filtering we shouldn't be restricted by that limitation as long as there are reasonable alternatives (and there are, e.g. IntelliJ; I switched exactly because of these types of issues :-) ). Besides, checkins have to be run through the mvn command line build process, not through an IDE. Jim This means people can make improvements to the build or project layout that are fine with Maven and the definitive build but which, for some reason, make Eclipse unhappy. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet another eclipse problem, was: svn commit: r440909...
On Sep 7, 2006, at 6:03 AM, ant elder wrote: I completely agree with Frank. Also whether or not it is possible to get free copies of IDEA is beside the point, a lot of people use Eclipse so we need to embrace that if we want to encourage them to contribute to Tuscany. And a lot of people use IDEA, Emacs, VI, etc. For example, most of the developers I know use IDEA and Emacs, not Eclipse (even though the Eclipse juggernaut has significantly more market share) . The point is twofold. We need to accommodate as many as possible, not just Eclipse users. The second is checking in unverifiable artifacts is bound to lead to a break at some point. ...ant On 9/7/06, Frank Budinsky [EMAIL PROTECTED] wrote: I would say that thinking about Eclipse as just one of a many IDEs that people may be using is totally off the mark. In reality, there are only a very few popular Java IDEs (two, actually), and Eclipse is the free one. So, in my opinion, not accommodating Eclipse seems ludicrous - it will inconvenience a lot of people. I would think that the more productive route would be to say that we officially support Eclipse and that we file Eclipse bug reports and/or create (temporary) workarounds to make sure that it works. Saying that people have an alternative (simply shelling out $500 for IDEA) doesn't sound very convincing to me either. I'm sorry but I believe thinking about Eclipse as just one of the many IDEs is completely valid. We need to be as open as possible, particularly since there is no good reason in my mind why we should anoint a particular IDE for Tuscany developers (and that goes for IDEA too). For me, the question is not about accommodating Eclipse but having a build process that works with the tool we chose, Maven, and making it easy for developers using a variety of tooling environments. Otherwise, we should use Eclipse to do the build and mandate that it is run prior to checkin ;-) The need to accommodate a variety of development environments is a balancing act. In the specific case that prompted Jeremy's rant, a problem in Eclipse resulted in the introduction of a change to the build process that makes working with Maven, particularly for distributions, extremely difficult. I think we should err on the side of Maven. Another example would be a hypothetical bug in, say, the IDEA compiler. If it only occurs in one place, maybe we could put a work-around in the code as long as it did not impact performance or cause drastic changes for others. If it required something like a performance hit or not using an important language feature, IDEA users would need to accommodate. If we find that Maven consistently causes problems for a wide variety of developers, then we should change to something better. Jim Frank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet another eclipse problem, was: svn commit: r440909...
On Sep 6, 2006, at 6:16 PM, Jeremy Boynes wrote:
On Sep 6, 2006, at 5:07 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Wed Sep 6 17:07:19 2006
New Revision: 440909
URL: http://svn.apache.org/viewvc?view=revrev=440909
Log:
Replace ${sca.version} in the SCDL files with 1.0-SNAPSHOT since
IDEs such as Eclipse cannot honor it.
rant
Specifically, Eclipse can't handle it - some other IDEs (cough)
don't have that problem. The result of this is that we end up with
version information referenced in many files rather than one which
is not very pleasant.
We made a decision early in the project that we would not tie
ourselves to one IDE but we continue to work around issues/defects
with Eclipse. These workarounds are not maintainable in an open
project where people are free to use different development tools as
a developer has no way of knowing if a change may break someone
else's tool.
Rather than continue down this path I would like to suggest that we
allow IDE configurations to be checked into SVN on the
understanding that they are not part of the project and that
changes to the Maven build or project structure may break them at
any time and that it is down to some committer using that
particular IDE to make it work again.
I think this is asking for trouble for several reasons. We really
should have one definitive source for the build. These artifacts are
bound to break and there is no realistic way to verify that they work
short of loading them in the tool they were intended for.
Alternatively, if we want to keep the policy of no-IDE-specific
artifacts at all, then we should bite the bullet on workarounds and
say that the Maven build is definitive and that IDE setup is the
responsibility of each developer - i.e. they need to set their IDE
to work with the environment as defined by the Maven build.
I prefer the current policy of having Maven categorically determine
the state of the build. My opinion is we should not allow checkins of
unverifiable artifacts.
Jim
/rant
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet another eclipse problem, was: svn commit: r440909...
On Sep 6, 2006, at 8:18 PM, Jim Marino wrote:
On Sep 6, 2006, at 6:16 PM, Jeremy Boynes wrote:
On Sep 6, 2006, at 5:07 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Wed Sep 6 17:07:19 2006
New Revision: 440909
URL: http://svn.apache.org/viewvc?view=revrev=440909
Log:
Replace ${sca.version} in the SCDL files with 1.0-SNAPSHOT since
IDEs such as Eclipse cannot honor it.
rant
Specifically, Eclipse can't handle it - some other IDEs (cough)
don't have that problem. The result of this is that we end up with
version information referenced in many files rather than one which
is not very pleasant.
We made a decision early in the project that we would not tie
ourselves to one IDE but we continue to work around issues/defects
with Eclipse. These workarounds are not maintainable in an open
project where people are free to use different development tools
as a developer has no way of knowing if a change may break someone
else's tool.
Rather than continue down this path I would like to suggest that
we allow IDE configurations to be checked into SVN on the
understanding that they are not part of the project and that
changes to the Maven build or project structure may break them at
any time and that it is down to some committer using that
particular IDE to make it work again.
I think this is asking for trouble for several reasons. We really
should have one definitive source for the build. These artifacts
are bound to break and there is no realistic way to verify that
they work short of loading them in the tool they were intended for.
There is still only one definitive build - the Maven one. All the
others are just (unverifiable) artifacts that may work for some
developers. The compensating factor here is that presumably some
active developers are using them and will keep them current and working.
Alternatively, if we want to keep the policy of no-IDE-specific
artifacts at all, then we should bite the bullet on workarounds
and say that the Maven build is definitive and that IDE setup is
the responsibility of each developer - i.e. they need to set their
IDE to work with the environment as defined by the Maven build.
I prefer the current policy of having Maven categorically determine
the state of the build. My opinion is we should not allow checkins
of unverifiable artifacts.
The problem is that we have requirements on checked in artifacts (the
Maven POM's) that are not verifiable using the Maven build -
requirements such as we can't use Maven's resource filtering because
Eclipse also copies resources and does not filter them, or Eclipse
cannot support the resource paths that Maven uses. There may be
others (for example, I don't know how or if Eclipse recognizes code
generated as part of the Maven build).
This means people can make improvements to the build or project
layout that are fine with Maven and the definitive build but which,
for some reason, make Eclipse unhappy.
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet another eclipse problem, was: svn commit: r440909...
I think this is asking for trouble for several reasons. We really should have one definitive source for the build. These artifacts are bound to break and there is no realistic way to verify that they work short of loading them in the tool they were intended for. There is still only one definitive build - the Maven one. All the others are just (unverifiable) artifacts that may work for some developers. The compensating factor here is that presumably some active developers are using them and will keep them current and working. I'm not sure it's definitive anymore due to all of the hidden requirements you mentioned below...Hoping people keep artifacts up to date is what I don't like as they will invariably break since they are not verifiable. Alternatively, if we want to keep the policy of no-IDE-specific artifacts at all, then we should bite the bullet on workarounds and say that the Maven build is definitive and that IDE setup is the responsibility of each developer - i.e. they need to set their IDE to work with the environment as defined by the Maven build. I prefer the current policy of having Maven categorically determine the state of the build. My opinion is we should not allow checkins of unverifiable artifacts. The problem is that we have requirements on checked in artifacts (the Maven POM's) that are not verifiable using the Maven build - requirements such as we can't use Maven's resource filtering because Eclipse also copies resources and does not filter them, or Eclipse cannot support the resource paths that Maven uses. There may be others (for example, I don't know how or if Eclipse recognizes code generated as part of the Maven build). That to me just seems wrong. We chose Maven to be our build system and we should use its features. If a particular IDE can't handle a basic thing thing such as resource filtering we shouldn't be restricted by that limitation as long as there are reasonable alternatives (and there are, e.g. IntelliJ; I switched exactly because of these types of issues :-) ). Besides, checkins have to be run through the mvn command line build process, not through an IDE. Jim This means people can make improvements to the build or project layout that are fine with Maven and the definitive build but which, for some reason, make Eclipse unhappy. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
