RE: XML entities and forward compatibility
Nicol, Carl wrote on Friday, June 11, 2004 1:55 AM: I tried to use an external entity file for the list of developers and could not get it to work. Can you inherit from more than one file? I'm autogenerating the developers list file from several others so I don't want to muck about my project.xml file. http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities Does this help ? -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: XML entities and forward compatibility
By the way, is it correct that the goal convert-snapshots does not work together with external entities in maven-rc-3? At least my tests showed that it would mess up the POM (and I understand that this is hard to do, how would you convert a dependency which is actually an entitiy reference?). We also thought about ensuring project consistency with entities, but details like this make me also believe that a separate, clean solution for maven would be better than abusing entities for this. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML entities and forward compatibility
I tried to use an external entity file for the list of developers and could not get it to work. Can you inherit from more than one file? I'm autogenerating the developers list file from several others so I don't want to muck about my project.xml file. Thanks... Carl Nicol -Original Message- From: Maczka Michal [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 09, 2004 2:33 AM To: 'Maven Users List' Subject:RE: XML entities and forward compatibility -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 09, 2004 3:24 AM To: Maven Users List Subject: Re: XML entities and forward compatibility Given that they're a standard part of XML, and that the m2 project descriptor in one form will be an XML document, why would they not be available? Because a) How would you deploy POMs which contains external XML entities to say ibiblio? The same problems - diffused files - may affect continuous integration tools - more files more problems to deal with b) XML representation of POM is not the only available and I hope we will be using mini databases for keeping them as this will enable faster processing. XML entities hve really no meaning for databases and they are not so friendly for futute tools like visual POM editor. d) imo ideally round trip XML - Bean Model -- XML or XML -- DB -- XML should leave POM untouched. And it will be hard to do this with external entities c) (most important) They won't be needed michal - 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: XML entities and forward compatibility
-Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 09, 2004 3:24 AM To: Maven Users List Subject: Re: XML entities and forward compatibility Given that they're a standard part of XML, and that the m2 project descriptor in one form will be an XML document, why would they not be available? Because a) How would you deploy POMs which contains external XML entities to say ibiblio? The same problems - diffused files - may affect continuous integration tools - more files more problems to deal with b) XML representation of POM is not the only available and I hope we will be using mini databases for keeping them as this will enable faster processing. XML entities hve really no meaning for databases and they are not so friendly for futute tools like visual POM editor. d) imo ideally round trip XML - Bean Model -- XML or XML -- DB -- XML should leave POM untouched. And it will be hard to do this with external entities c) (most important) They won't be needed michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML entities and forward compatibility
Hi Jason, Jason van Zyl wrote on Wednesday, June 09, 2004 3:22 AM: On Tue, 2004-06-08 at 19:23, Tim Reilly wrote: Does anyone know, or can anyone comment on whether external xml entities in the POM (particularly for dependencies) will continue to work or be supported in future versions (maven-2, etc)? You won't need them and the plexus and geronimo builds will be proof of that. Today was infact the first day a build using arbitrary recursive inheritance and transitive dependencies occurred. Michal finished checking in his wagon integration into m2, I tweaked it a bit and presto! A new level of manageability. I really, really, really don't want to promote the use of entities. I've kept my mouth shut because they were really the only way to work around some congenital problems in m1. m2 is a ways off and there will be some surveys for users and one of questions will be regarding the use of entities. No one will probably want to use them anyway with m2. My basic concern was about the consistent versions in the dependencies. Say, have a multiproject with ~50 subprojects and ~10 of them use e.g. xstream. Using entities I change currently only one single line in one file to upgrade all of this 10 subprojects for a new xstream version and does not have to care about, if possibly someone added a xstream dependency to another subproject I currently do not know. Without entities I have in M1 to make all subprojects dependend of XStream to achieve the same ... what about M2? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML entities and forward compatibility
Hi Jason, it's really good to have a better mechanism in place but breaking existing Maven project using XML entities is another thing - you can always issue a deprecation warning during the build or POM validation. Thanks in advance Siegfried Goeschl -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 09. Juni 2004 03:51 To: Maven Users List Subject: Re: XML entities and forward compatibility On Tue, 2004-06-08 at 21:24, Dion Gillard wrote: Given that they're a standard part of XML, and that the m2 project descriptor in one form will be an XML document, why would they not be available? If decided that the native mechanisms would work best, which I definitely think would be the case as there would be one standard way that work whereas the use of XML entities could be used in any fashion, then I would disable their use them in the xpp3 parser. I honestly cannot see any cases where entities would be beneficial with what's running now in m2. Also, with some of the more advanced features in m2 for conflict resolution amongst dependencies, better jar overriding, and better general handling of artifacts exact control over processing becomes necessary. I would really like to avoid having to locate the source of a problem by finding the source of an entity. In addition things like accurate authoring will have difficulty dealing with entities. If you, say, have a GUI that is allowing you to fix a conflict, or align dependencies then we can provide the exact information to client code to find the source of the conflict. I don't see any upside to entities at all in m2 and I think they would actually be harmful. Nothing special happens with the processing of XML in m1 so it doesn't really matter. But sophisticated tools will need exacting control whether than be our own like the conflict resolution mechanism or GUI tools. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - 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: XML entities and forward compatibility
Maczka Michal wrote on Wednesday, June 09, 2004 9:33 AM: Because a) How would you deploy POMs which contains external XML entities to say ibiblio? The same problems - diffused files - may affect continuous integration tools - more files more problems to deal with This is not a problem of the entities!!! I already stated that some time ago. Look at M1 multiprojects. The deployed pom's of their subprojects are useless also! If you would extract the resolved POM from memory and deploy that ... you would solve the real problem. b) XML representation of POM is not the only available and I hope we will be using mini databases for keeping them as this will enable faster processing. XML entities hve really no meaning for databases and they are not so friendly for futute tools like visual POM editor. And how would you deploy a POM contained in a DB? Same as (a) d) imo ideally round trip XML - Bean Model -- XML or XML -- DB -- XML should leave POM untouched. And it will be hard to do this with external entities Valid argument. But see, I not insist on entities per se, but on the flexibility that they give me at that places I currently use them. c) (most important) They won't be needed That's my use case for M2. Currently with M1 I have several Multiproject that have a dependency on each other. With company wide entity definitions I manage even inter-project dependencies and their versions. This means there is e.g. only one xstream version that is used company wide, although a multiproject may overwrite this version-entity for its subprojects. This ensures largely, that all unit tests for all subprojects in all multiprojects that have to work together use (normally) the same versions and I will not be bitten by incompatible versions in the dependencies running my app in the test (or live) env although all unit test were originally working (but only with their project's specific version). SUch a mechanism I would like to achive also with M2. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML entities and forward compatibility
-Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 09, 2004 10:03 AM To: Maven Users List Subject: RE: XML entities and forward compatibility Maczka Michal wrote on Wednesday, June 09, 2004 9:33 AM: Because a) How would you deploy POMs which contains external XML entities to say ibiblio? The same problems - diffused files - may affect continuous integration tools - more files more problems to deal with This is not a problem of the entities!!! I already stated that some time ago. Look at M1 multiprojects. The deployed pom's of their subprojects are useless also! If you would extract the resolved POM from memory and deploy that ... you would solve the real problem. I am not sure if I know what you mean but in m2 parent POM will be referenced differently (not by the way of giving path to it) and reactor will be built-in into core. Also raw model is well separated from inherited and interpolated values. b) XML representation of POM is not the only available and I hope we will be using mini databases for keeping them as this will enable faster processing. XML entities hve really no meaning for databases and they are not so friendly for futute tools like visual POM editor. And how would you deploy a POM contained in a DB? Same as (a) yeap. c) (most important) They won't be needed That's my use case for M2. Currently with M1 I have several Multiproject that have a dependency on each other. With company wide entity definitions I manage even inter-project dependencies and their versions. This means there is e.g. only one xstream version that is used company wide, although a multiproject may overwrite this version-entity for its subprojects. This ensures largely, that all unit tests for all subprojects in all multiprojects that have to work together use (normally) the same versions and I will not be bitten by incompatible versions in the dependencies running my app in the test (or live) env although all unit test were originally working (but only with their project's specific version). SUch a mechanism I would like to achive also with M2. There are few things which will be vanished by transitive dependencies: Now all project which were using xstream or whcih were using libraries which we using xstream have to declare a dependency on xstream. With transitive dependencies in place the number of POMs which have to do this will be greatly limited. This will already make maintenance a lot easier. Secondly we hope to have some tools which will help you manage your POMs. Say you will be able to group projects and with GUI tool update the version of the given dependency in all those projects. Or imagine ci system doing that for you when new, fully backward compatible version of xstream is released. And there are some other cool things coming E.g. you will be able to use your own types of dependencies and artifact handlers for creating artifacts from them. If someone will wish he might be even able to write artifact handler which will read other POMs or even use web services. I doubt if such complex things will be ever needed but that is something which will possible. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML entities and forward compatibility
Maczka Michal wrote on Wednesday, June 09, 2004 11:15 AM: -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] [...] This is not a problem of the entities!!! I already stated that some time ago. Look at M1 multiprojects. The deployed pom's of their subprojects are useless also! If you would extract the resolved POM from memory and deploy that ... you would solve the real problem. I am not sure if I know what you mean well, for M1, if you do a war-install in a subproject of a multiproject layout, the deployed POM will have an extends tag ... but the referenced POM is nowhere ... but in m2 parent POM will be referenced differently (not by the way of giving path to it) and reactor will be built-in into core. Also raw model is well separated from inherited and interpolated values. OK. [snip] There are few things which will be vanished by transitive dependencies: Now all project which were using xstream or whcih were using libraries which we using xstream have to declare a dependency on xstream. With transitive dependencies in place the number of POMs which have to do this will be greatly limited. This will already make maintenance a lot easier. Secondly we hope to have some tools which will help you manage your POMs. Say you will be able to group projects and with GUI tool update the version of the given dependency in all those projects. Or imagine ci system doing that for you when new, fully backward compatible version of xstream is released. And there are some other cool things coming E.g. you will be able to use your own types of dependencies and artifact handlers for creating artifacts from them. If someone will wish he might be even able to write artifact handler which will read other POMs or even use web services. I doubt if such complex things will be ever needed but that is something which will possible. Sounds interesting. M2 is definitely on my target, all your speed-ups is looking promising. But I fear I will have major changes to my current infrastructure ... -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML entities and forward compatibility
On Wed, 2004-06-09 at 07:02, Jörg Schaible wrote: Sounds interesting. M2 is definitely on my target, all your speed-ups is looking promising. But I fear I will have major changes to my current infrastructure ... This is after all 2.0 and you can use 1.x for as long as you like. If you want to take advantage of some of the nifty features in m2 then you'll need to move your POMs foward. This we certainly don't expect everyone to do and we are actually planning to 1) be able to run v3 POMs in m2 and 2) for the ones detected not to work for whatever reason a converion GUI will be provided and we can certainly take into account entities as part of the conversion process with the help of users. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML entities and forward compatibility
Jörg Schaible [wrote] My basic concern was about the consistent versions in the dependencies. Say, have a multiproject with ~50 subprojects and ~10 of them use e.g. xstream. Using entities I change currently only one single line in one file to upgrade all of this 10 subprojects for a new xstream version and does not have to care about, if possibly someone added a xstream dependency to another subproject I currently do not know. Yes, This is the use case that prompted my question. The goal is to provide version consistency among dependent jars for the 20 to 30 so projects many of which will share the same jar within the application server. Currently this maintenance is done with eyeballs on each file. The gui tool to manage and/or report across multiple POMs sounds terrific. I look forward to it. Thanks, -TR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XML entities and forward compatibility
Does anyone know, or can anyone comment on whether external xml entities in the POM (particularly for dependencies) will continue to work or be supported in future versions (maven-2, etc)? Before making so many changes... just want verify. TIA, -TR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML entities and forward compatibility
On Tue, 2004-06-08 at 21:24, Dion Gillard wrote: Given that they're a standard part of XML, and that the m2 project descriptor in one form will be an XML document, why would they not be available? If decided that the native mechanisms would work best, which I definitely think would be the case as there would be one standard way that work whereas the use of XML entities could be used in any fashion, then I would disable their use them in the xpp3 parser. I honestly cannot see any cases where entities would be beneficial with what's running now in m2. Also, with some of the more advanced features in m2 for conflict resolution amongst dependencies, better jar overriding, and better general handling of artifacts exact control over processing becomes necessary. I would really like to avoid having to locate the source of a problem by finding the source of an entity. In addition things like accurate authoring will have difficulty dealing with entities. If you, say, have a GUI that is allowing you to fix a conflict, or align dependencies then we can provide the exact information to client code to find the source of the conflict. I don't see any upside to entities at all in m2 and I think they would actually be harmful. Nothing special happens with the processing of XML in m1 so it doesn't really matter. But sophisticated tools will need exacting control whether than be our own like the conflict resolution mechanism or GUI tools. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML entities and forward compatibility
Character entities (#1234;) are handy though, for storing 16 bit unicode chars in a utf8/ascii project.xml. Hopefully xpp3 distinguishes character entities from external entities. --Jeff On Tue, Jun 08, 2004 at 09:50:41PM -0400, Jason van Zyl wrote: On Tue, 2004-06-08 at 21:24, Dion Gillard wrote: Given that they're a standard part of XML, and that the m2 project descriptor in one form will be an XML document, why would they not be available? If decided that the native mechanisms would work best, which I definitely think would be the case as there would be one standard way that work whereas the use of XML entities could be used in any fashion, then I would disable their use them in the xpp3 parser. I honestly cannot see any cases where entities would be beneficial with what's running now in m2. Also, with some of the more advanced features in m2 for conflict resolution amongst dependencies, better jar overriding, and better general handling of artifacts exact control over processing becomes necessary. I would really like to avoid having to locate the source of a problem by finding the source of an entity. In addition things like accurate authoring will have difficulty dealing with entities. If you, say, have a GUI that is allowing you to fix a conflict, or align dependencies then we can provide the exact information to client code to find the source of the conflict. I don't see any upside to entities at all in m2 and I think they would actually be harmful. Nothing special happens with the processing of XML in m1 so it doesn't really matter. But sophisticated tools will need exacting control whether than be our own like the conflict resolution mechanism or GUI tools. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - 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: XML entities and forward compatibility
On Tue, 2004-06-08 at 23:20, Jeff Turner wrote: Character entities (#1234;) are handy though, for storing 16 bit unicode chars in a utf8/ascii project.xml. Hopefully xpp3 distinguishes character entities from external entities. I believe they do, but the source is so small it wouldn't be hard to wangle it in. --Jeff On Tue, Jun 08, 2004 at 09:50:41PM -0400, Jason van Zyl wrote: On Tue, 2004-06-08 at 21:24, Dion Gillard wrote: Given that they're a standard part of XML, and that the m2 project descriptor in one form will be an XML document, why would they not be available? If decided that the native mechanisms would work best, which I definitely think would be the case as there would be one standard way that work whereas the use of XML entities could be used in any fashion, then I would disable their use them in the xpp3 parser. I honestly cannot see any cases where entities would be beneficial with what's running now in m2. Also, with some of the more advanced features in m2 for conflict resolution amongst dependencies, better jar overriding, and better general handling of artifacts exact control over processing becomes necessary. I would really like to avoid having to locate the source of a problem by finding the source of an entity. In addition things like accurate authoring will have difficulty dealing with entities. If you, say, have a GUI that is allowing you to fix a conflict, or align dependencies then we can provide the exact information to client code to find the source of the conflict. I don't see any upside to entities at all in m2 and I think they would actually be harmful. Nothing special happens with the processing of XML in m1 so it doesn't really matter. But sophisticated tools will need exacting control whether than be our own like the conflict resolution mechanism or GUI tools. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - 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] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
