Re: project.xml is a jelly script?
On Fri, 2003-08-15 at 00:30, Jason Dillon wrote: > > Specifically I was looking for a way to define common dependencies for > a large project (Apache Geronimo) so I could better manage version > numbers of the dependencies. I did not wish to put all of the depends > into a parent project as that would force each child project to have > additional dependencies on its classpath which might not be a good > thing, nor do I want each and every module to try to download > SNAPSHOTS, especially if they do not even need that depend. > > So I thought about using properties like > 'dependency.commons-logger.version=1.0.3' and then specify the property > as the content for , which works fine if the property is > defined in the child modules project.properties, or if the property is > in the parent and the child is always invoked through the reactor. > This is not the case with Geronimo, so this method fails. I've done this - as you've probably found, at the moment you can't inherit the contents of project.properties along with the project.xml that you extend, so doesn't give you a mechanism for pulling in shared property values. Similarly you can't use maven.xml (which is a jelly script) because it's not parsed until after the POM has been completely processed. You can set property values in maven.xml but they aren't available at the time interpolation is performed on the POM. And you can't put jelly into the POM as it's not a jelly script. What I've done is store the properties in a text file and then have each developer add the contents of that file to ~/build.properties. It's not exactly a clean approach, and you need to make sure that you keep ~/build.properties in sync with the stuff in the source tree, but it does work. I guess it should be possible to write some code in maven.xml to check that the defined properties from ~/build.properties match thos in the file in the source tree. And it seems there's a good chance of being able to move the information into the parent project's project.properties file in the future when inherits property settings too, so eventually the hack can go away. -Mark. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project.xml is a jelly script?
On Sun, 2003-08-17 at 00:16, Jason van Zyl wrote: > On Sat, 2003-08-16 at 16:35, Luke Taylor wrote: > > > > I think the problem is that you might want to put shared dependencies > > into a parent project file for a reactor project which has, for example, > > 20 sub-projects/components. But if perhaps only 10 of them actually use > > the dependencies, they will still have to be available for building the > > others individually. > > Ok, that I don't quite understand. There is just a fear of polluting the > classpath? Yeah, that would be my concern. For example, you might have certain sub-projects that shouldn't be doing anything with XML, but if you inherit all your dependencies from the parent project you loose the ability to verify these architectural constraints at compile time. Probably more important, if your project contains sub-projects common, framework, shared, front-end, back-end and ui, you might want to make sure that ui only depends on front-end, shared, framework and common, but that it's depending on the same versions of shared, framework and common that the back-end project is depending on. -Mark. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project.xml is a jelly script?
On Sat, 2003-08-16 at 19:19, Jason van Zyl wrote: > On Sat, 2003-08-16 at 12:11, Mark McBride wrote: > > My group is currently running into the same problem.What we are doing is > > declaring all our system/lib jars in a projects.xml which all our > > projects extend. This is nice in respect to ensure that everyone is > > building/debugging against the libraries that are in production. We are > > actually using this parent project.xml to document our system > > configuration. > > > > The problem we run into is that, like stated earlier in this thread, we > > lose on the meaningfulness of the dependencies documentation in all the > > projects that extend the parent project.xml. Our system library has 50 > > jars and many of our application are only using a handful more then the > > standard java server libraries. > > What if in the reports you could distinguish between the dependencies > stated for the project directly versus those that are inherited? This > could generalized and methods in the POM could be added to select the > stated versus inherited dependencies. That would be great! > > > Another concept that we think would be a good feature of maven is the > > ability to state a group of dependencies, say struts and all it's > > libraries. > > This actually works in the maven-new code where you do this by stating a > POM of another project as a dependency. And transitive dependencies also > work in maven-new. I've just had zero time of late. Sounds good! Looking forward to using it! > > > This would be stated in a xml file that declares all the jars > > that struts uses. This xml file could be stored in the maven central > > repository so that projects that want to use struts 1.1 and all related > > libraries could declare (maybe call it a "group dependency") this file > > in it's project.xml and when doing builds maven would pull down the > > struts dependency list and then check if those libraries have been > > downloaded to the developers local repository. > > This is what we are trying to achieve by starting to store POMs for > projects in the repository. As mentioned before, having POM dependencies > and transitive dependencies isn't a technical problem it's getting all > the POMs into the repository. > > > We tend to use frameworks > > that consist of 5+ libraries which all depend on each other.Managing > > dependencies through "groups" of libraries would ease setting up new > > projects, and give more structure to dependencies. > > What you want is transitive dependencies. It's coming, well the code > actaully exists it's a matter of merging it. > > > I'm not sure of how hard this would be to implement, whether it would be > > to hack the project.xml or go directly into the maven impl??? I'd be > > willing to work on this functionality if others (committers +) thought > > this was a good idea/approach. > > It is a good idea and already works but the code is splayed between > what's now in HEAD and what's in maven-new. I'm in the process of > starting a new business but once the infrastructure is done I plan to > take a little Maven vacation. There is certainly nothing more I would > like to do than get all the code merged so users can take advantage of > it. My committment hasn't waned I am just at a critical stage in a new > endeavour and it takes priority. One thing that I'm hoping will force me > to complete things is the writing of a book on Maven. I have only > chatted with some folks at O'Reilly and there is by no means anything > even remotely certain but I'm hoping I can convince them to let me right > a book with the help of a couple other folks. I'm hoping for the best. I hope you write the book, maven is a really awesome technology that could use a full book to help new users. > > > -Mark > > > > > > On Sat, 2003-08-16 at 14:17, Paul Libbrecht wrote: > > > Is the idea of a dependency role not something that would possibly help > > > here ? > > > > > > Aside of basic-roles like "building", "running-tests", etc, a project > > > should even be able to specify roles depending on the runtime behaviour > > > expected. > > > > > > Dependency inclusion (which is planned in some maven future I thought) > > > could then be extended to respect this role. > > > > > > This doesn't answer, however, a possible attribute like "dependency on > > > xxx version a to b" which was alluded first. > > > > > > Paul > > > > > > > > > Luke Taylor wrote: > > > > Jason van Zyl wrote: > > > >> Dependencies are inherited in an aggregate fashion. So if you have > > > >> common dependencies then you can state them in a parent project. In much > > > >> the same way the Jelly tag builds are setup. > > > >> > > > >> > > > >>> I did not wish to put all of the depends into a parent project as > > > >>> that would force each child project to have additional dependencies > > > >>> on its classpath which might not be a good thing, nor do I want each > > > >>> and every module to try to downloa
Re: project.xml is a jelly script?
Mark, Mark McBride <[EMAIL PROTECTED]> wrote on 17/08/2003 02:11:52 AM: > My group is currently running into the same problem.What we are doing is > declaring all our system/lib jars in a projects.xml which all our > projects extend. This is nice in respect to ensure that everyone is > building/debugging against the libraries that are in production. We are > actually using this parent project.xml to document our system > configuration. We declare dependencies on a per project basis and use the convergence report to stay in synch. > Another concept that we think would be a good feature of maven is the > ability to state a group of dependencies, say struts and all it's > libraries. This would be stated in a xml file that declares all the jars > that struts uses. This xml file could be stored in the maven central > repository so that projects that want to use struts 1.1 and all related > libraries could declare (maybe call it a "group dependency") this file > in it's project.xml and when doing builds maven would pull down the > struts dependency list and then check if those libraries have been > downloaded to the developers local repository.We tend to use frameworks > that consist of 5+ libraries which all depend on each other.Managing > dependencies through "groups" of libraries would ease setting up new > projects, and give more structure to dependencies. Transitive dependencies have been discussed and are planned to be implemented. All that's missing is a volunteer or time. > I'm not sure of how hard this would be to implement, whether it would be > to hack the project.xml or go directly into the maven impl??? I'd be > willing to work on this functionality if others (committers +) thought > this was a good idea/approach. The approach that's been discussed is for a project to list another project's 'pom' in it's dependencies and for the dependency verifier/ resolver to work out what they are at run time and add them in. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/
Re: project.xml is a jelly script?
Jason Dillon <[EMAIL PROTECTED]> wrote on 15/08/2003 09:30:05 AM:
> Hello, the website says that "project.xml form, is now processed as a
> Jelly script "
> (http://maven.apache.org/reference/user-guide.html#POM%20Interpolation
> ) but it does not appear to be having like it is a jelly script at all.
>
> Is the user guide not valid? Is there a special property to enable
No, it's not.
> this? I have looked over the source and it does not appear that any
> jelly fluff is done to the project.xml file.
Interpolation of elements is allowed, using ${pom}.
> IMO I think that it would be very beneficial if it was a jelly script
> so that Maven in general is more flexible. I understand not wanting to
> put much logic into the project.xml, but it would make management of
> large projects much easier.
Can you give me some use cases? The multiproject plugin was written to
address exactly these issues.
> Specifically I was looking for a way to define common dependencies for
> a large project (Apache Geronimo) so I could better manage version
> numbers of the dependencies. I did not wish to put all of the depends
> into a parent project as that would force each child project to have
> additional dependencies on its classpath which might not be a good
> thing, nor do I want each and every module to try to download
> SNAPSHOTS, especially if they do not even need that depend.
This can be done by specifying a parent project using
> So I thought about using properties like
> 'dependency.commons-logger.version=1.0.3' and then specify the property
> as the content for , which works fine if the property is
> defined in the child modules project.properties, or if the property is
> in the parent and the child is always invoked through the reactor.
> This is not the case with Geronimo, so this method fails.
>
> James and I were chatting about this a tad... I was under the
> impression that I could use jelly in project.xml (drawn conclusion from
> web page and some bad tests I made). He suggested using xml="../../dependencies.xml"/> and then selecting out dependencies by
> name and then copying them into the project.xml. I think this would be
> very useful and shows where project.xml as a jelly script would be
> desirable.
Why not just use XML entities?
> I think this is a good idea, but wanted to hear what you guys have to
> say.
>
> Also I was talking to James about the problem of versioning
> dependencies in general and how it would make sense if Maven supported
> more symbolic names (similar to SNAPSHOT) but which could point to the
> latest stable release. It probably makes sense to provide some sort of
> version alias mechanism, as it becomes problematic to effectively
> maintain version numbers in a large project. Take Maven for example,
> there are a few plugins which use different yet compatible versions of
> dependencies, which only results in additional overhead. If all
> plugins are compatible with a specific version, then it would make
> sense for them to all use that version.
Yep. See the dependency convergence report as part of the multiproject
plugin:
http://maven.apache.org/dependency-convergence-report.html
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Re: project.xml is a jelly script?
On Sat, 2003-08-16 at 12:11, Mark McBride wrote: > My group is currently running into the same problem.What we are doing is > declaring all our system/lib jars in a projects.xml which all our > projects extend. This is nice in respect to ensure that everyone is > building/debugging against the libraries that are in production. We are > actually using this parent project.xml to document our system > configuration. > > The problem we run into is that, like stated earlier in this thread, we > lose on the meaningfulness of the dependencies documentation in all the > projects that extend the parent project.xml. Our system library has 50 > jars and many of our application are only using a handful more then the > standard java server libraries. What if in the reports you could distinguish between the dependencies stated for the project directly versus those that are inherited? This could generalized and methods in the POM could be added to select the stated versus inherited dependencies. > Another concept that we think would be a good feature of maven is the > ability to state a group of dependencies, say struts and all it's > libraries. This actually works in the maven-new code where you do this by stating a POM of another project as a dependency. And transitive dependencies also work in maven-new. I've just had zero time of late. > This would be stated in a xml file that declares all the jars > that struts uses. This xml file could be stored in the maven central > repository so that projects that want to use struts 1.1 and all related > libraries could declare (maybe call it a "group dependency") this file > in it's project.xml and when doing builds maven would pull down the > struts dependency list and then check if those libraries have been > downloaded to the developers local repository. This is what we are trying to achieve by starting to store POMs for projects in the repository. As mentioned before, having POM dependencies and transitive dependencies isn't a technical problem it's getting all the POMs into the repository. > We tend to use frameworks > that consist of 5+ libraries which all depend on each other.Managing > dependencies through "groups" of libraries would ease setting up new > projects, and give more structure to dependencies. What you want is transitive dependencies. It's coming, well the code actaully exists it's a matter of merging it. > I'm not sure of how hard this would be to implement, whether it would be > to hack the project.xml or go directly into the maven impl??? I'd be > willing to work on this functionality if others (committers +) thought > this was a good idea/approach. It is a good idea and already works but the code is splayed between what's now in HEAD and what's in maven-new. I'm in the process of starting a new business but once the infrastructure is done I plan to take a little Maven vacation. There is certainly nothing more I would like to do than get all the code merged so users can take advantage of it. My committment hasn't waned I am just at a critical stage in a new endeavour and it takes priority. One thing that I'm hoping will force me to complete things is the writing of a book on Maven. I have only chatted with some folks at O'Reilly and there is by no means anything even remotely certain but I'm hoping I can convince them to let me right a book with the help of a couple other folks. I'm hoping for the best. > -Mark > > > On Sat, 2003-08-16 at 14:17, Paul Libbrecht wrote: > > Is the idea of a dependency role not something that would possibly help > > here ? > > > > Aside of basic-roles like "building", "running-tests", etc, a project > > should even be able to specify roles depending on the runtime behaviour > > expected. > > > > Dependency inclusion (which is planned in some maven future I thought) > > could then be extended to respect this role. > > > > This doesn't answer, however, a possible attribute like "dependency on > > xxx version a to b" which was alluded first. > > > > Paul > > > > > > Luke Taylor wrote: > > > Jason van Zyl wrote: > > >> Dependencies are inherited in an aggregate fashion. So if you have > > >> common dependencies then you can state them in a parent project. In much > > >> the same way the Jelly tag builds are setup. > > >> > > >> > > >>> I did not wish to put all of the depends into a parent project as > > >>> that would force each child project to have additional dependencies > > >>> on its classpath which might not be a good thing, nor do I want each > > >>> and every module to try to download SNAPSHOTS, especially if they do > > >>> not even need that depend. > > >> > > >> > > >> > > >> Sorry, don't understand that one. You want a common set of dependencies > > >> but don't want them in the classpath? What do you want to use those > > >> common dependencies for? > > >> > > > > > > I think the problem is that you might want to put shared dependencies > > > into a parent project file for a reactor p
Re: project.xml is a jelly script?
My group is currently running into the same problem.What we are doing is declaring all our system/lib jars in a projects.xml which all our projects extend. This is nice in respect to ensure that everyone is building/debugging against the libraries that are in production. We are actually using this parent project.xml to document our system configuration. The problem we run into is that, like stated earlier in this thread, we lose on the meaningfulness of the dependencies documentation in all the projects that extend the parent project.xml. Our system library has 50 jars and many of our application are only using a handful more then the standard java server libraries. Another concept that we think would be a good feature of maven is the ability to state a group of dependencies, say struts and all it's libraries. This would be stated in a xml file that declares all the jars that struts uses. This xml file could be stored in the maven central repository so that projects that want to use struts 1.1 and all related libraries could declare (maybe call it a "group dependency") this file in it's project.xml and when doing builds maven would pull down the struts dependency list and then check if those libraries have been downloaded to the developers local repository.We tend to use frameworks that consist of 5+ libraries which all depend on each other.Managing dependencies through "groups" of libraries would ease setting up new projects, and give more structure to dependencies. I'm not sure of how hard this would be to implement, whether it would be to hack the project.xml or go directly into the maven impl??? I'd be willing to work on this functionality if others (committers +) thought this was a good idea/approach. -Mark On Sat, 2003-08-16 at 14:17, Paul Libbrecht wrote: > Is the idea of a dependency role not something that would possibly help > here ? > > Aside of basic-roles like "building", "running-tests", etc, a project > should even be able to specify roles depending on the runtime behaviour > expected. > > Dependency inclusion (which is planned in some maven future I thought) > could then be extended to respect this role. > > This doesn't answer, however, a possible attribute like "dependency on > xxx version a to b" which was alluded first. > > Paul > > > Luke Taylor wrote: > > Jason van Zyl wrote: > >> Dependencies are inherited in an aggregate fashion. So if you have > >> common dependencies then you can state them in a parent project. In much > >> the same way the Jelly tag builds are setup. > >> > >> > >>> I did not wish to put all of the depends into a parent project as > >>> that would force each child project to have additional dependencies > >>> on its classpath which might not be a good thing, nor do I want each > >>> and every module to try to download SNAPSHOTS, especially if they do > >>> not even need that depend. > >> > >> > >> > >> Sorry, don't understand that one. You want a common set of dependencies > >> but don't want them in the classpath? What do you want to use those > >> common dependencies for? > >> > > > > I think the problem is that you might want to put shared dependencies > > into a parent project file for a reactor project which has, for example, > > 20 sub-projects/components. But if perhaps only 10 of them actually use > > the dependencies, they will still have to be available for building the > > others individually. Of course, you can specify the dependencies > > individually in each component but then you have to maintain all the > > versions separately even though you want to use the same version > > throughout. Does the standard artifact version stuff you mentioned cover > > this scenario? > > > > The dependency list is also useful high-level documentation on what is > > required for each component and how it works, but this information is > > lost if it is put in the parent file. > > > > Luke. > > > > > > > > - > 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: project.xml is a jelly script?
Jason van Zyl wrote: On Sat, 2003-08-16 at 16:35, Luke Taylor wrote: Jason van Zyl wrote: Dependencies are inherited in an aggregate fashion. So if you have common dependencies then you can state them in a parent project. In much the same way the Jelly tag builds are setup. I did not wish to put all of the depends into a parent project as that would force each child project to have additional dependencies on its classpath which might not be a good thing, nor do I want each and every module to try to download SNAPSHOTS, especially if they do not even need that depend. Sorry, don't understand that one. You want a common set of dependencies but don't want them in the classpath? What do you want to use those common dependencies for? I think the problem is that you might want to put shared dependencies into a parent project file for a reactor project which has, for example, 20 sub-projects/components. But if perhaps only 10 of them actually use the dependencies, they will still have to be available for building the others individually. Ok, that I don't quite understand. There is just a fear of polluting the classpath? I can't speak for the Geronimo project. From my point of view it's not a huge issue (downloading extra jars certainly isn't a problem), but I prefer to see the dependencies listed per-component. The version properties you mentioned will probably allow that without any problems. Of course, you can specify the dependencies individually in each component but then you have to maintain all the versions separately even though you want to use the same version throughout. Does the standard artifact version stuff you mentioned cover this scenario? Yes, if you override the version of an artifact at build.properties level you can control the versioning. This mechanism is far from perfect and doesn't work because of some inheritance problems in general, in this particular case properties. The code in HEAD deals with this much better but is not for general consumption at the moment. OK, great. That sounds pretty useful. So you don't have to specify your own version properties. Does that follow a kind of .. syntax? I realise inheritance of properties is still a bit hosed. If it will work at some stage then that's worth knowing :). The dependency list is also useful high-level documentation on what is required for each component and how it works, but this information is lost if it is put in the parent file. It shouldn't be. I intentionally made the xdoc plugin to work with the resultant POM after any transformations due to inheritance and/or interpolation. If this is not the case now then someone whacked it. I just actually checked with a component that inherits and the inherited dependencies do indeed show up in the dependency report. OK, slight misunderstanding. I shouldn't have said that the info is "lost". I meant that the global dependencies will show up as requirements for all the components, rather than just those to which they actually apply. So the detail is "lost" rather than the actual information - all you know is that a subset of the components use the dependencies in the root POM. Thanks, Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project.xml is a jelly script?
On Sat, 2003-08-16 at 16:35, Luke Taylor wrote: > Jason van Zyl wrote: > > > > Dependencies are inherited in an aggregate fashion. So if you have > > common dependencies then you can state them in a parent project. In much > > the same way the Jelly tag builds are setup. > > > > > >>I did not wish to put all of the depends > >>into a parent project as that would force each child project to have > >>additional dependencies on its classpath which might not be a good > >>thing, nor do I want each and every module to try to download > >>SNAPSHOTS, especially if they do not even need that depend. > > > > > > Sorry, don't understand that one. You want a common set of dependencies > > but don't want them in the classpath? What do you want to use those > > common dependencies for? > > > > I think the problem is that you might want to put shared dependencies > into a parent project file for a reactor project which has, for example, > 20 sub-projects/components. But if perhaps only 10 of them actually use > the dependencies, they will still have to be available for building the > others individually. Ok, that I don't quite understand. There is just a fear of polluting the classpath? > Of course, you can specify the dependencies > individually in each component but then you have to maintain all the > versions separately even though you want to use the same version > throughout. Does the standard artifact version stuff you mentioned cover > this scenario? Yes, if you override the version of an artifact at build.properties level you can control the versioning. This mechanism is far from perfect and doesn't work because of some inheritance problems in general, in this particular case properties. The code in HEAD deals with this much better but is not for general consumption at the moment. > The dependency list is also useful high-level documentation on what is > required for each component and how it works, but this information is > lost if it is put in the parent file. It shouldn't be. I intentionally made the xdoc plugin to work with the resultant POM after any transformations due to inheritance and/or interpolation. If this is not the case now then someone whacked it. I just actually checked with a component that inherits and the inherited dependencies do indeed show up in the dependency report. > Luke. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project.xml is a jelly script?
Is the idea of a dependency role not something that would possibly help here ? Aside of basic-roles like "building", "running-tests", etc, a project should even be able to specify roles depending on the runtime behaviour expected. Dependency inclusion (which is planned in some maven future I thought) could then be extended to respect this role. This doesn't answer, however, a possible attribute like "dependency on xxx version a to b" which was alluded first. Paul Luke Taylor wrote: Jason van Zyl wrote: Dependencies are inherited in an aggregate fashion. So if you have common dependencies then you can state them in a parent project. In much the same way the Jelly tag builds are setup. I did not wish to put all of the depends into a parent project as that would force each child project to have additional dependencies on its classpath which might not be a good thing, nor do I want each and every module to try to download SNAPSHOTS, especially if they do not even need that depend. Sorry, don't understand that one. You want a common set of dependencies but don't want them in the classpath? What do you want to use those common dependencies for? I think the problem is that you might want to put shared dependencies into a parent project file for a reactor project which has, for example, 20 sub-projects/components. But if perhaps only 10 of them actually use the dependencies, they will still have to be available for building the others individually. Of course, you can specify the dependencies individually in each component but then you have to maintain all the versions separately even though you want to use the same version throughout. Does the standard artifact version stuff you mentioned cover this scenario? The dependency list is also useful high-level documentation on what is required for each component and how it works, but this information is lost if it is put in the parent file. Luke. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project.xml is a jelly script?
Jason van Zyl wrote: Dependencies are inherited in an aggregate fashion. So if you have common dependencies then you can state them in a parent project. In much the same way the Jelly tag builds are setup. I did not wish to put all of the depends into a parent project as that would force each child project to have additional dependencies on its classpath which might not be a good thing, nor do I want each and every module to try to download SNAPSHOTS, especially if they do not even need that depend. Sorry, don't understand that one. You want a common set of dependencies but don't want them in the classpath? What do you want to use those common dependencies for? I think the problem is that you might want to put shared dependencies into a parent project file for a reactor project which has, for example, 20 sub-projects/components. But if perhaps only 10 of them actually use the dependencies, they will still have to be available for building the others individually. Of course, you can specify the dependencies individually in each component but then you have to maintain all the versions separately even though you want to use the same version throughout. Does the standard artifact version stuff you mentioned cover this scenario? The dependency list is also useful high-level documentation on what is required for each component and how it works, but this information is lost if it is put in the parent file. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project.xml is a jelly script?
On Thu, 2003-08-14 at 19:30, Jason Dillon wrote: > Hello, the website says that "project.xml form, is now processed as a > Jelly script " > (http://maven.apache.org/reference/user-guide.html#POM%20Interpolation > ) but it does not appear to be having like it is a jelly script at all. Yes, I removed the Jelly script stuff a while ago but the interpolation remains. I decided it was probably a very bad idea to bind the descriptor to Jelly. I still feel that. > Is the user guide not valid? Is there a special property to enable > this? I have looked over the source and it does not appear that any > jelly fluff is done to the project.xml file. > > IMO I think that it would be very beneficial if it was a jelly script > so that Maven in general is more flexible. I understand not wanting to > put much logic into the project.xml, but it would make management of > large projects much easier. I think the use cases would have to surface before making the project.xml file a jelly script. I honestly think I jumped the gun on that one. > Specifically I was looking for a way to define common dependencies for > a large project (Apache Geronimo) so I could better manage version > numbers of the dependencies. Dependencies are inherited in an aggregate fashion. So if you have common dependencies then you can state them in a parent project. In much the same way the Jelly tag builds are setup. > I did not wish to put all of the depends > into a parent project as that would force each child project to have > additional dependencies on its classpath which might not be a good > thing, nor do I want each and every module to try to download > SNAPSHOTS, especially if they do not even need that depend. Sorry, don't understand that one. You want a common set of dependencies but don't want them in the classpath? What do you want to use those common dependencies for? > So I thought about using properties like > 'dependency.commons-logger.version=1.0.3' and then specify the property > as the content for , which works fine if the property is > defined in the child modules project.properties, or if the property is > in the parent and the child is always invoked through the reactor. > This is not the case with Geronimo, so this method fails. Have you looked at the jar overrided feature which allows you to set a standard version of an artifact? > James and I were chatting about this a tad... I was under the > impression that I could use jelly in project.xml (drawn conclusion from > web page and some bad tests I made). He suggested using xml="../../dependencies.xml"/> and then selecting out dependencies by > name and then copying them into the project.xml. I think this would be > very useful and shows where project.xml as a jelly script would be > desirable. > > I think this is a good idea, but wanted to hear what you guys have to > say. I think it would be generally undesirable. I just don't want to see Jelly in the project XML directly. But I wouldn't be opposed to some sort of optional filtering mechanism so you could use Jelly or anything else you wanted to. > Also I was talking to James about the problem of versioning > dependencies in general and how it would make sense if Maven supported > more symbolic names (similar to SNAPSHOT) but which could point to the > latest stable release. The idea of RELEASE has been discussed, just not implemented. You can put it in JIRA so we can track it. > It probably makes sense to provide some sort of > version alias mechanism, as it becomes problematic to effectively > maintain version numbers in a large project. Take Maven for example, > there are a few plugins which use different yet compatible versions of > dependencies, which only results in additional overhead. If all > plugins are compatible with a specific version, then it would make > sense for them to all use that version. Within Maven it's more the classloader isolation problem. The versions should be allowed to vary. But in the case of Geronimo if you were attempting to use the same version overall you can use the jar override feature. > Anyways I have been up for way too long, it was light when I woke up > and it is light again, so I am gonna crash now. > > Cheers, > > --jason -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project.xml is a jelly script?
Jason Dillon wrote: So I thought about using properties like 'dependency.commons-logger.version=1.0.3' and then specify the property as the content for , which works fine if the property is defined in the child modules project.properties, or if the property is in the parent and the child is always invoked through the reactor. This is not the case with Geronimo, so this method fails. I remember thinking this would be a good idea too (using properties to specify versions for use in subprojects. I think Jason (VZ) said recently that the intention is for the parent properties to be inherited in any case, though that may not be the case with the current version of Maven. So in theory this should work OK. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project.xml is a jelly script?
Jason, To my taste, this looks awesomely great! (though dangerous, as said) Your ideas on implications for management of dependencies are clearly something neat. For example, we have a dependency.xml for each dependency (with a bunch of documentation) I see other implications in the sense of a project.xml being actually a shadow of a project in another language, for example, most projects built from GUI tools. (I think it would enable for example an Apple's ProjectBuilder file to have a shadow maven project). One essential thing here, is, however, how much of jelly taglibs we have in there. jelly:xml is clearly needed, but parsers for other formats as well... would this be dynamic as a good jelly-runner (still not existing) would involve ? Thats essentially great news to my taste! Paul PS: the example provided in the website seems to invoke delicate possibly recursive resolution of pom... will there be any policy about that ? It might be very parse-dependent (well, jelly dependent then). Jason Dillon wrote: Hello, the website says that "project.xml form, is now processed as a Jelly script " (http://maven.apache.org/reference/user-guide.html#POM%20Interpolation ) but it does not appear to be having like it is a jelly script at all. Is the user guide not valid? Is there a special property to enable this? I have looked over the source and it does not appear that any jelly fluff is done to the project.xml file. IMO I think that it would be very beneficial if it was a jelly script so that Maven in general is more flexible. I understand not wanting to put much logic into the project.xml, but it would make management of large projects much easier. Specifically I was looking for a way to define common dependencies for a large project (Apache Geronimo) so I could better manage version numbers of the dependencies. I did not wish to put all of the depends into a parent project as that would force each child project to have additional dependencies on its classpath which might not be a good thing, nor do I want each and every module to try to download SNAPSHOTS, especially if they do not even need that depend. So I thought about using properties like 'dependency.commons-logger.version=1.0.3' and then specify the property as the content for , which works fine if the property is defined in the child modules project.properties, or if the property is in the parent and the child is always invoked through the reactor. This is not the case with Geronimo, so this method fails. James and I were chatting about this a tad... I was under the impression that I could use jelly in project.xml (drawn conclusion from web page and some bad tests I made). He suggested using and then selecting out dependencies by name and then copying them into the project.xml. I think this would be very useful and shows where project.xml as a jelly script would be desirable. I think this is a good idea, but wanted to hear what you guys have to say. Also I was talking to James about the problem of versioning dependencies in general and how it would make sense if Maven supported more symbolic names (similar to SNAPSHOT) but which could point to the latest stable release. It probably makes sense to provide some sort of version alias mechanism, as it becomes problematic to effectively maintain version numbers in a large project. Take Maven for example, there are a few plugins which use different yet compatible versions of dependencies, which only results in additional overhead. If all plugins are compatible with a specific version, then it would make sense for them to all use that version. Anyways I have been up for way too long, it was light when I woke up and it is light again, so I am gonna crash now. Cheers, --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
project.xml is a jelly script?
Hello, the website says that "project.xml form, is now processed as a Jelly script " (http://maven.apache.org/reference/user-guide.html#POM%20Interpolation ) but it does not appear to be having like it is a jelly script at all. Is the user guide not valid? Is there a special property to enable this? I have looked over the source and it does not appear that any jelly fluff is done to the project.xml file. IMO I think that it would be very beneficial if it was a jelly script so that Maven in general is more flexible. I understand not wanting to put much logic into the project.xml, but it would make management of large projects much easier. Specifically I was looking for a way to define common dependencies for a large project (Apache Geronimo) so I could better manage version numbers of the dependencies. I did not wish to put all of the depends into a parent project as that would force each child project to have additional dependencies on its classpath which might not be a good thing, nor do I want each and every module to try to download SNAPSHOTS, especially if they do not even need that depend. So I thought about using properties like 'dependency.commons-logger.version=1.0.3' and then specify the property as the content for , which works fine if the property is defined in the child modules project.properties, or if the property is in the parent and the child is always invoked through the reactor. This is not the case with Geronimo, so this method fails. James and I were chatting about this a tad... I was under the impression that I could use jelly in project.xml (drawn conclusion from web page and some bad tests I made). He suggested using and then selecting out dependencies by name and then copying them into the project.xml. I think this would be very useful and shows where project.xml as a jelly script would be desirable. I think this is a good idea, but wanted to hear what you guys have to say. Also I was talking to James about the problem of versioning dependencies in general and how it would make sense if Maven supported more symbolic names (similar to SNAPSHOT) but which could point to the latest stable release. It probably makes sense to provide some sort of version alias mechanism, as it becomes problematic to effectively maintain version numbers in a large project. Take Maven for example, there are a few plugins which use different yet compatible versions of dependencies, which only results in additional overhead. If all plugins are compatible with a specific version, then it would make sense for them to all use that version. Anyways I have been up for way too long, it was light when I woke up and it is light again, so I am gonna crash now. Cheers, --jason
