RE: Mutliple source directories in project.xml
-Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Sunday, January 11, 2004 10:54 PM To: Maven Users List Subject: RE: Mutliple source directories in project.xml On Sat, 2004-01-10 at 18:34, John Casey wrote: It seems to me that the POM is the wrong place to put anything related to artifacts created during maven execution. I'd even go so far as to say that the list of reports to be generated doesn't belong in here. I don't agree, and I have changed my mind a couple times along the way but the report element is a registry essentially and says what reports you want for the projects. I happen to think the POM is the place for it. For configuring each of the plugins that produce those reports, probably not. I think they are! see your own comments below: I'm not sure what you mean by pure: as far as I have always thought, the POM would describe everything about a project. I often see myself working at a nice GUI tool operating on the project. From this perspective, and to the user of this tool, whether things come from properties files or the POM is irrelavent. The use of properties files came into use simply because of their convenience and people being accustomed to them in Ant. Exactly. For me POM = project.xml + project.properties. Maybe even maven.xml is a part of POM (it contains definition of goals which can be inherited by other projects) So we can imagine methods like: ListGoal Project.getGoals() (returns all goals implemented in maven.xml file of given project + all inherited goals) which can be inherited by child projects. As far as I understand it today when POM will be read from database, ldap there will be no differnce between things which are coming from project.xml, project.properties or maven.xml. my 2 cents Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mutliple source directories in project.xml
-Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Subject: RE: Mutliple source directories in project.xml It seems to me that the POM is the wrong place to put anything related to artifacts created during maven execution. I tend to agree with this, but in my case, the generated artifacts are abstract base classes and factory classes, one of each for every entity, generated from a UML model (somewhat critical to the success of the goals... ;) The correct implementation is likely that the XMI has special representation in the POM, but is this just a specific case of a bigger problem? If so, there will never be an end to this issue as new metamodels are introduced. XDoclet is a tricky case of this because it is mixing two sources of information (java classes and class metadata) into a single source set. The problem with the POM might be the inability to differentiate between vanilla source and source that is seasoned with XDoclet tags (or aspects, etc...). It is a similar argument to the premise against projects having multiple artifacts. If I understand the POM correctly, it almost seems that Maven could use pluggable providers for various metamodels, allowing for it to direct generation during build and querying of the project from a component/PM perspective. Querying a project model but omitting the class metadata gives an incomplete picture of the project, reducing the effectiveness of eventual tools that will be able to query POMs on the net like Google (Poogle? :). Imagine being very happy with a particular component and doing a backwards links search for components that use it. If metamodels are not available for querying (XDoclet, UML via XMI, etc.) much of that information could be unavailable. I'd even go so far as to say that the list of reports to be generated doesn't belong in here. To me, it makes sense to have the POM describe the project itself, in pure terms, without making assumptions about what artifacts will be generated. It seems to me that the POM should be both a director to the generation of artifacts as well as an indicator to the existence of artifacts. In a potential alternate universe, the transitive closure of POMs through dependencies includes all components ever built under various Maven installations. This mirrors the web itself, but uses POM instead of HTML for hyperlinking. Imagining that such a world existed, a developer could import a class by name, and the IDE would automagically look it up in a hypothetical POM search engine, then update the POM with the correct dependency. Or maybe Maven starts to form the idea of a build container, and a Java compiler that is executing uses an import resolution service of the container for issues such as missing imports. But without indication that an artifact (such as a report) existed, the engine would have a harder time to find it. Could POM search engine functionality be the metric by which inclusion in the POM is measured? If so, how do generated artifacts fit in now? To that end, configuring things like the generated source directory should take place in project.properties instead of the POM. Obviously, it's not acceptable to try to configure the list of reports via project.properties, but somehow this information should also be excluded from the POM. In general, operational information used in maven execution but not having any use outside of maven SHOULD NOT be in the POM. This will leave open the opportunity for the POM to outlive maven's current incarnation. Accomplishing this will make the POM much more stable, and will mean that users won't be penalized by having to rewrite POMs for each update to a maven plugin. It should also reduce the requirements involved in providing backwards compatibility. -john -b - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mutliple source directories in project.xml
On Sun, 2004-01-11 at 14:30, Brian Topping wrote: -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Subject: RE: Mutliple source directories in project.xml It seems to me that the POM is the wrong place to put anything related to artifacts created during maven execution. I tend to agree with this, but in my case, the generated artifacts are abstract base classes and factory classes, one of each for every entity, generated from a UML model (somewhat critical to the success of the goals... ;) The correct implementation is likely that the XMI has special representation in the POM, but is this just a specific case of a bigger problem? If so, there will never be an end to this issue as new metamodels are introduced. XDoclet is a tricky case of this because it is mixing two sources of information (java classes and class metadata) into a single source set. The problem with the POM might be the inability to differentiate between vanilla source and source that is seasoned with XDoclet tags (or aspects, etc...). It is a similar argument to the premise against projects having multiple artifacts. If I understand the POM correctly, it almost seems that Maven could use pluggable providers for various metamodels, allowing for it to direct generation during build and querying of the project from a component/PM perspective. Querying a project model but omitting the class metadata gives an incomplete picture of the project, reducing the effectiveness of eventual tools that will be able to query POMs on the net like Google (Poogle? :). Imagine being very happy with a particular component and doing a backwards links search for components that use it. If metamodels are not available for querying (XDoclet, UML via XMI, etc.) much of that information could be unavailable. I don't think I agree with this. The POM seems like a construct which essentially defines the structure of a project, without making any assumptions about the type of project it is. We can specify things like source directory, dependencies, unit test directories, and supporting files for compiles, etc. within this structure. In spite of current implementations which for good reason favor Java, the POM seems language-agnostic, in that it seems to try to capture the abstract data which would be required to build artifacts based on any type of project, in any language. For instance, in the case of XMI, it seems to me that the XMI files _are_ the source of the project, and the production of Java code based on them is a _generation_ step along the way toward building a particular type of artifact. It's not compulsory that this step take place; for instance, if you're simply documenting the project (as in the site:site target), you might not even be interested in the Java intermediaries. Taking this perspective, we don't need to muddy the waters with pluggable metamodels. Once you introduce such a concept, you have to define how each maven plugin will respond to different metamodels, and probably will have to allow for compound models (XMI with second-stage XDoclet, JavaCC, or antlr, for instance), which makes maven unimaginably complex to code for. Plugin development probably would grind to a halt in the face of this complexity. As far as search engine accessibility, it might be more simple to say that these would in fact search for some sort of standardized, generated info file which would contain the pertinent details of the project, much as the site deliverable does now, in the form of a directory structure. This way, the generation of the .info (or whatever) file could depend upon the type of sources in the source directory (or the type specification of the project, which currently doesn't exist). I still maintain that the project descriptor (which is after all what the POM is) should not contain any information about n-stage build operations. These should be completely contained within the plugin/plugin configuration (i.e. the project.properties, etc.) because that eliminates the need to change the POM every time a plugin's needs change. Sure, a change to a plugin in this new model might break one type of build in a particular project until the changes propagate to that project, but it _wouldn't_break_all_builds_. Each time you modify the POM, you have two problems: 1. Huge deprecation support issues. (Supporting old POM formats) 2. An extremely time-consuming upgrade path for your users, as POM deprecations become unsupported. I think continued modification of the POM is a real problem which will affect the viability of maven as a de-facto replacement for Ant in codebase management. I'd even go so far as to say that the list of reports to be generated doesn't belong in here. To me, it makes sense to have the POM describe the project itself, in pure terms, without making assumptions about what artifacts will be generated. It seems to me that the POM should
RE: Mutliple source directories in project.xml
On Sat, 2004-01-10 at 18:34, John Casey wrote: It seems to me that the POM is the wrong place to put anything related to artifacts created during maven execution. I'd even go so far as to say that the list of reports to be generated doesn't belong in here. I don't agree, and I have changed my mind a couple times along the way but the report element is a registry essentially and says what reports you want for the projects. I happen to think the POM is the place for it. For configuring each of the plugins that produce those reports, probably not. To me, it makes sense to have the POM describe the project itself, in pure terms, without making assumptions about what artifacts will be generated. I'm not sure what you mean by pure: as far as I have always thought, the POM would describe everything about a project. I often see myself working at a nice GUI tool operating on the project. From this perspective, and to the user of this tool, whether things come from properties files or the POM is irrelavent. The use of properties files came into use simply because of their convenience and people being accustomed to them in Ant. To that end, configuring things like the generated source directory should take place in project.properties instead of the POM. I myself don't think so, I think a default value in a base POM inherited by all projects would be more useful. Obviously, it's not acceptable to try to configure the list of reports via project.properties, but somehow this information should also be excluded from the POM. Again, I don't agree. I see that as being important information and should be part of the POM. I see a similiar mechanism for testing where there is a registry for running various test plugins. To accurately report on what reports are being generated or what test plugins are being run. In general, operational information used in maven execution but not having any use outside of maven SHOULD NOT be in the POM. Operational? This will leave open the opportunity for the POM to outlive maven's current incarnation. Accomplishing this will make the POM much more stable, and will mean that users won't be penalized by having to rewrite POMs for each update to a maven plugin. It should also reduce the requirements involved in providing backwards compatibility. With changes being done something has to change whether it be the POM itself or properties files, but that being said the POM has still not undergone any radical changes is probabaly not likely to and after 1.1 and we have the structure worked out (as I think we can with the massive amount of input we have now) it will most likely be additions. -john On Fri, 2004-01-09 at 15:19, Michal Maczka wrote: -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 6:28 PM To: Maven Users List Subject: RE: Mutliple source directories in project.xml On Fri, 2004-01-09 at 11:33, Maczka Michal wrote: Because it is not necessary to have this aspect configurable How do you know this for certain? The answer is you can't without feedback from users over time. Sure I cannot I just looked at antlr, castor and xdoclet plugin. Myself I have written jaxb and javacc plugins. But the point is that is easier to make something configurable then lock it after. So we can always add an extra property. But it's generally harder to make it other way around. Most of the code generators provides a possibility to customize output directory. There is many plugin which are generating reports and which have hardcoded the well known location: {maven.build.dir}/generated-xdocs Sure, but ultimately I think this should come from the POM. An inherited POM for all projects so that specification of all these things is as easy as using the properties files are currrently, but in the POM nonetheless. Example: (taken from SIMIAN plugin) ant:simian output=${maven.build.dir}/generated-xdocs/simian.log lineCount=${maven.simian.linecount} failOnDuplication=${maven.simian.failonduplication} And report generators are extremely plugable and they just works. Sure, this is because people generally copy one report to make another and get ${maven.build.dir}/generated-xdocs. Do you not think it would be better to have a standard element that could be used like: ${pom.generatedDocmentDirectory} I am all for strongly typed way of expressing things (If I can I prefer to stay away from jelly :))! But maybe some of the properties may be read-only? I am simply afraid that this will be misused. That's the major problem with jelly properties. It's easier to remember /target/generated-xdocs then ${maven.build.dir}/{i_even_dont_know_what_stands_for_generated-xdocs} Our use of properties
RE: Mutliple source directories in project.xml
incarnation. Accomplishing this will make the POM much more stable, and will mean that users won't be penalized by having to rewrite POMs for each update to a maven plugin. It should also reduce the requirements involved in providing backwards compatibility. With changes being done something has to change whether it be the POM itself or properties files, but that being said the POM has still not undergone any radical changes is probabaly not likely to and after 1.1 and we have the structure worked out (as I think we can with the massive amount of input we have now) it will most likely be additions. -john On Fri, 2004-01-09 at 15:19, Michal Maczka wrote: -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 6:28 PM To: Maven Users List Subject: RE: Mutliple source directories in project.xml On Fri, 2004-01-09 at 11:33, Maczka Michal wrote: Because it is not necessary to have this aspect configurable How do you know this for certain? The answer is you can't without feedback from users over time. Sure I cannot I just looked at antlr, castor and xdoclet plugin. Myself I have written jaxb and javacc plugins. But the point is that is easier to make something configurable then lock it after. So we can always add an extra property. But it's generally harder to make it other way around. Most of the code generators provides a possibility to customize output directory. There is many plugin which are generating reports and which have hardcoded the well known location: {maven.build.dir}/generated-xdocs Sure, but ultimately I think this should come from the POM. An inherited POM for all projects so that specification of all these things is as easy as using the properties files are currrently, but in the POM nonetheless. Example: (taken from SIMIAN plugin) ant:simian output=${maven.build.dir}/generated-xdocs/simian.log lineCount=${maven.simian.linecount} failOnDuplication=${maven.simian.failonduplication} And report generators are extremely plugable and they just works. Sure, this is because people generally copy one report to make another and get ${maven.build.dir}/generated-xdocs. Do you not think it would be better to have a standard element that could be used like: ${pom.generatedDocmentDirectory} I am all for strongly typed way of expressing things (If I can I prefer to stay away from jelly :))! But maybe some of the properties may be read-only? I am simply afraid that this will be misused. That's the major problem with jelly properties. It's easier to remember /target/generated-xdocs then ${maven.build.dir}/{i_even_dont_know_what_stands_for_generated-xdocs} Our use of properties on one hand and ${pom} elements in other cases is rather arbitrary and if we are going to move toward one mechanism I would be for the ${pom}. Providing a parent with all the defaults so we still have the convenience we do now with some added consistency. But my thought would be that a parent POM would have a generateSourceDirectory/ that is the default that would be inherited. If we are right in that nobody cares then we will never see that element show up in POMs. Once we start getting POMs into the repo then at least for the population of OSS projects uploading things we could actually tell for certain within that population of projects what is being done. Sure. Learing from experience and touching the reality is probably the best option. (After all we have always a possiblity of doing things as we maven developers want, not as crowd of users wants.) [...] 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] - 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: Mutliple source directories in project.xml
It seems to me that the POM is the wrong place to put anything related to artifacts created during maven execution. I'd even go so far as to say that the list of reports to be generated doesn't belong in here. To me, it makes sense to have the POM describe the project itself, in pure terms, without making assumptions about what artifacts will be generated. To that end, configuring things like the generated source directory should take place in project.properties instead of the POM. Obviously, it's not acceptable to try to configure the list of reports via project.properties, but somehow this information should also be excluded from the POM. In general, operational information used in maven execution but not having any use outside of maven SHOULD NOT be in the POM. This will leave open the opportunity for the POM to outlive maven's current incarnation. Accomplishing this will make the POM much more stable, and will mean that users won't be penalized by having to rewrite POMs for each update to a maven plugin. It should also reduce the requirements involved in providing backwards compatibility. -john On Fri, 2004-01-09 at 15:19, Michal Maczka wrote: -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 6:28 PM To: Maven Users List Subject: RE: Mutliple source directories in project.xml On Fri, 2004-01-09 at 11:33, Maczka Michal wrote: Because it is not necessary to have this aspect configurable How do you know this for certain? The answer is you can't without feedback from users over time. Sure I cannot I just looked at antlr, castor and xdoclet plugin. Myself I have written jaxb and javacc plugins. But the point is that is easier to make something configurable then lock it after. So we can always add an extra property. But it's generally harder to make it other way around. Most of the code generators provides a possibility to customize output directory. There is many plugin which are generating reports and which have hardcoded the well known location: {maven.build.dir}/generated-xdocs Sure, but ultimately I think this should come from the POM. An inherited POM for all projects so that specification of all these things is as easy as using the properties files are currrently, but in the POM nonetheless. Example: (taken from SIMIAN plugin) ant:simian output=${maven.build.dir}/generated-xdocs/simian.log lineCount=${maven.simian.linecount} failOnDuplication=${maven.simian.failonduplication} And report generators are extremely plugable and they just works. Sure, this is because people generally copy one report to make another and get ${maven.build.dir}/generated-xdocs. Do you not think it would be better to have a standard element that could be used like: ${pom.generatedDocmentDirectory} I am all for strongly typed way of expressing things (If I can I prefer to stay away from jelly :))! But maybe some of the properties may be read-only? I am simply afraid that this will be misused. That's the major problem with jelly properties. It's easier to remember /target/generated-xdocs then ${maven.build.dir}/{i_even_dont_know_what_stands_for_generated-xdocs} Our use of properties on one hand and ${pom} elements in other cases is rather arbitrary and if we are going to move toward one mechanism I would be for the ${pom}. Providing a parent with all the defaults so we still have the convenience we do now with some added consistency. But my thought would be that a parent POM would have a generateSourceDirectory/ that is the default that would be inherited. If we are right in that nobody cares then we will never see that element show up in POMs. Once we start getting POMs into the repo then at least for the population of OSS projects uploading things we could actually tell for certain within that population of projects what is being done. Sure. Learing from experience and touching the reality is probably the best option. (After all we have always a possiblity of doing things as we maven developers want, not as crowd of users wants.) [...] 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: Mutliple source directories in project.xml
There will always be some hairy cases where something Maven does isn't compatible with a given method but the generatedSourceDirectory/ would go a long way to making things better. In the cases where things are hairy, as John said, you can always whip something together in your maven.xml file. -- jvz. -1 for generatedSourceDirectory/ sourceDirectory and other things in POM exists only because maven cannot (yet :) ) impose common directory structure of projects (e.g. where sourceDirectory is fixed to location like src/main/java) But nothing on Earth can stop us from doing things in standard way inside target directory!!! and we are free to do whatever we want inside target directory and force plugins to cooperate via well defined directory structure. For example the following rules can be imposed on plugins the following rules on plugins: a) All artifacts generated by project are put to /target/repository/${artifact_path} where ${artifact_path} matches artifact path in local/remote repository b) All Java source code generator generate their stuff into /target/generated/java Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mutliple source directories in project.xml
Why is it a bad idea? How is it any different than having /target/docs a property that all plugins CAN use? It's not hardcoded and can be changed by users that want to change the location of the files. I'm not seeing how this is any different. The target directory is not a free-for-all where plugins throw crap wherever they want. There will always be some hairy cases where something Maven does isn't compatible with a given method but the generatedSourceDirectory/ would go a long way to making things better. In the cases where things are hairy, as John said, you can always whip something together in your maven.xml file. -- jvz. -1 for generatedSourceDirectory/ sourceDirectory and other things in POM exists only because maven cannot (yet :) ) impose common directory structure of projects (e.g. where sourceDirectory is fixed to location like src/main/java) But nothing on Earth can stop us from doing things in standard way inside target directory!!! and we are free to do whatever we want inside target directory and force plugins to cooperate via well defined directory structure. For example the following rules can be imposed on plugins the following rules on plugins: a) All artifacts generated by project are put to /target/repository/${artifact_path} where ${artifact_path} matches artifact path in local/remote repository b) All Java source code generator generate their stuff into /target/generated/java 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: Mutliple source directories in project.xml
-Original Message- From: Sonnek, Ryan [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 4:59 PM To: 'Maven Users List' Subject: RE: Mutliple source directories in project.xml Why is it a bad idea? How is it any different than having /target/docs a property that all plugins CAN use? It's not hardcoded and can be changed by users that want to change the location of the files. I'm not seeing how this is any different. The target directory is not a free-for-all where plugins throw crap wherever they want. Because it is not necessary to have this aspect configurable There is many plugin which are generating reports and which have hardcoded the well known location: {maven.build.dir}/generated-xdocs Example: (taken from SIMIAN plugin) ant:simian output=${maven.build.dir}/generated-xdocs/simian.log lineCount=${maven.simian.linecount} failOnDuplication=${maven.simian.failonduplication} And report generators are extremely plugable and they just works. It's simply useless and not wise to make evry thing configurable. Standards are not configurable. Why would anybody care about it if it has a reasonable well know location? The contract for a report generator is simple: put generated files to {maven.build.dir}/generated-xdocs. I don't know anybody who ever even tried to change this location. We just live with it. I am sure the same can happen to source code generators. If today we have reports reportxx/report /reports We can imagine ( I personally think that one source generator per project is the maximum and this is just an example which illustrates my way of thinking) javaSourceGenerators javaSourceGenratorjavacc/javaSourceGenrator javaSourceGenratorxdoclet/javaSourceGenrator javaSourceGenerators byteCodeEnhancers byteCodeEnhancerkodo/byteCodeEnhancer byteCodeEnhancerweblogicEJBCompiler/byteCodeEnhancer /byteCodeEnhancers and dozen other categories of tools. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mutliple source directories in project.xml
On Fri, 2004-01-09 at 03:06, Maczka Michal wrote: There will always be some hairy cases where something Maven does isn't compatible with a given method but the generatedSourceDirectory/ would go a long way to making things better. In the cases where things are hairy, as John said, you can always whip something together in your maven.xml file. -- jvz. -1 for generatedSourceDirectory/ sourceDirectory and other things in POM exists only because maven cannot (yet :) ) impose common directory structure of projects (e.g. where sourceDirectory is fixed to location like src/main/java) But nothing on Earth can stop us from doing things in standard way inside target directory!!! Yes, but this is exactly why at first you can't just pick a hard wired spot to begin because we really have no idea how it will be used. You know that I personally am all for locking things down but this can only happen over time. I would tend to agree that a single location for generated sources would probably work. It well may turn out that it doesn't and specifying generatedSourceDirectory/ at least provides a consistent way for the entity to be used in plugins. and we are free to do whatever we want inside target directory and force plugins to cooperate via well defined directory structure. Having ${pom.build.generatedSourceDirectory} would provide a way for plugins to cooperate. And I believe the explicit declaration is a good thing. Even if it eventually happens to be in a POM that all projects inherit. For example the following rules can be imposed on plugins the following rules on plugins: a) All artifacts generated by project are put to /target/repository/${artifact_path} where ${artifact_path} matches artifact path in local/remote repository b) All Java source code generator generate their stuff into /target/generated/java I don't think you can impose the rules yet until you let people use it for a while. I'm all for locking things down over time but I honestly don't do a lot of source generation so I don't really know how it would play out. -- 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: Mutliple source directories in project.xml
On Fri, 2004-01-09 at 11:33, Maczka Michal wrote: Because it is not necessary to have this aspect configurable How do you know this for certain? The answer is you can't without feedback from users over time. There is many plugin which are generating reports and which have hardcoded the well known location: {maven.build.dir}/generated-xdocs Sure, but ultimately I think this should come from the POM. An inherited POM for all projects so that specification of all these things is as easy as using the properties files are currrently, but in the POM nonetheless. Example: (taken from SIMIAN plugin) ant:simian output=${maven.build.dir}/generated-xdocs/simian.log lineCount=${maven.simian.linecount} failOnDuplication=${maven.simian.failonduplication} And report generators are extremely plugable and they just works. Sure, this is because people generally copy one report to make another and get ${maven.build.dir}/generated-xdocs. Do you not think it would be better to have a standard element that could be used like: ${pom.generatedDocmentDirectory} Our use of properties on one hand and ${pom} elements in other cases is rather arbitrary and if we are going to move toward one mechanism I would be for the ${pom}. Providing a parent with all the defaults so we still have the convenience we do now with some added consistency. It's simply useless and not wise to make evry thing configurable. Standards are not configurable. You are preaching to the choir :-) I understand what you are saying. Why would anybody care about it if it has a reasonable well know location? I don't think they would, but as we have seen some people do and sometimes have a valid reason even though I would agree people generally want things because they just want them because that's what they are used to doing. But my thought would be that a parent POM would have a generateSourceDirectory/ that is the default that would be inherited. If we are right in that nobody cares then we will never see that element show up in POMs. Once we start getting POMs into the repo then at least for the population of OSS projects uploading things we could actually tell for certain within that population of projects what is being done. If we find it's never being overridden,great. If we find that it is then we can do something about it. Aside from transitive dependencies this is one of the biggest reasons I want to get POMs into the repository. To start gleaning some facts about POM usage. The contract for a report generator is simple: put generated files to {maven.build.dir}/generated-xdocs. Sure, I'll I'm saying is make that part of a standard POM instead of a property and let people choose if they must for whatever reason. It would easy enough for people to circumvent ${maven.build.dir}/generated-xdocs if they really wanted to, but in most cases they don't. Just as I'm sure the same would be the case for a standard inherited element in the POM. I just want to get rid of the arbitrary distinction between what is a property and isn't. All reports use ${maven.build.dir}/generated-xdocs which is still subject to typos. Whereas most plugins dealing with sources use ${pom.build.sourceDirectory} where within the POM you are still subject to typos but a plugin could be made to puke when a ${pom.X} didn't exist. I'm all for locking things down and have always wanted to move to standardization for everything. I think we can achieve that with a parent POM which has all our recommended options if people want to deviate that's their choice. I don't know anybody who ever even tried to change this location. We just live with it. I am sure the same can happen to source code generators. Certainly. If today we have reports reportxx/report /reports We can imagine ( I personally think that one source generator per project is the maximum and this is just an example which illustrates my way of thinking) See, this you can't do because you are limiting people to the tools they might use for their projects. We've already had an example in the last couple days of someone generating sources and then running xdoclet over the generated sources. javaSourceGenerators javaSourceGenratorjavacc/javaSourceGenrator javaSourceGenratorxdoclet/javaSourceGenrator javaSourceGenerators byteCodeEnhancers byteCodeEnhancerkodo/byteCodeEnhancer byteCodeEnhancerweblogicEJBCompiler/byteCodeEnhancer /byteCodeEnhancers and dozen other categories of tools. Eventually we could categorize things for easy navigating and searching for tools but I'm not sure how this block above relates to the argument at hand. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new
RE: Mutliple source directories in project.xml
-Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 6:28 PM To: Maven Users List Subject: RE: Mutliple source directories in project.xml On Fri, 2004-01-09 at 11:33, Maczka Michal wrote: Because it is not necessary to have this aspect configurable How do you know this for certain? The answer is you can't without feedback from users over time. Sure I cannot I just looked at antlr, castor and xdoclet plugin. Myself I have written jaxb and javacc plugins. But the point is that is easier to make something configurable then lock it after. So we can always add an extra property. But it's generally harder to make it other way around. Most of the code generators provides a possibility to customize output directory. There is many plugin which are generating reports and which have hardcoded the well known location: {maven.build.dir}/generated-xdocs Sure, but ultimately I think this should come from the POM. An inherited POM for all projects so that specification of all these things is as easy as using the properties files are currrently, but in the POM nonetheless. Example: (taken from SIMIAN plugin) ant:simian output=${maven.build.dir}/generated-xdocs/simian.log lineCount=${maven.simian.linecount} failOnDuplication=${maven.simian.failonduplication} And report generators are extremely plugable and they just works. Sure, this is because people generally copy one report to make another and get ${maven.build.dir}/generated-xdocs. Do you not think it would be better to have a standard element that could be used like: ${pom.generatedDocmentDirectory} I am all for strongly typed way of expressing things (If I can I prefer to stay away from jelly :))! But maybe some of the properties may be read-only? I am simply afraid that this will be misused. That's the major problem with jelly properties. It's easier to remember /target/generated-xdocs then ${maven.build.dir}/{i_even_dont_know_what_stands_for_generated-xdocs} Our use of properties on one hand and ${pom} elements in other cases is rather arbitrary and if we are going to move toward one mechanism I would be for the ${pom}. Providing a parent with all the defaults so we still have the convenience we do now with some added consistency. But my thought would be that a parent POM would have a generateSourceDirectory/ that is the default that would be inherited. If we are right in that nobody cares then we will never see that element show up in POMs. Once we start getting POMs into the repo then at least for the population of OSS projects uploading things we could actually tell for certain within that population of projects what is being done. Sure. Learing from experience and touching the reality is probably the best option. (After all we have always a possiblity of doing things as we maven developers want, not as crowd of users wants.) [...] Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mutliple source directories in project.xml
Hi all I've seen that there has been a discussion regarding this before (at least on the mailing list). I gather one can circumvent this by modifying the appropriate property/variable in a preGoal (like maven.compile.src.set), but that would add to the maintenance workload and really it'd just be a hack. So my question is; will support for multiple source directories in the POM ever be incuded, or is it absolutely out of the question? Regard, Jan-Helge
RE: Mutliple source directories in project.xml
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 9:43 AM To: 'Maven Users List' Subject: Mutliple source directories in project.xml Hi all I've seen that there has been a discussion regarding this before (at least on the mailing list). I gather one can circumvent this by modifying the appropriate property/variable in a preGoal (like maven.compile.src.set), but that would add to the maintenance workload and really it'd just be a hack. So my question is; will support for multiple source directories in the POM ever be incuded, or is it absolutely out of the question? Chances for that are very low! [off topic] In reality there is quite often more than one java source directory. Recently I have a pleasure to work with a few tools which are generating java code (e.g. javacc). I can perfectly understand the frustration of people trying to do the same thing and knowing maven worst then me. Even if generated source become visible for java compiler plugin, javadoc plugin is not seeing them. ( it uses ant:fileset dir=${pom.build.sourceDirectory}) I think we can do and we should do something to make those things simpler. Most of plugins which are generating java source like antlr, xdoclet, hibernate are changing ant classpath which is processed by java:compile goal. I think that this strategy is not perfect as it's breaks encapsulation of plugins and exposes their implementation details. Such process should be based on some simple contracts which give a freedom how plugins are implemented (e.g. ant should not be necessary for javac:compile goal) The solution could be very simple: every source generator can put its files into the well known place (e.g. target/generated/java ). then javac, javadoc and whatever else can do simple check if such directory exists and behave appropriately. Generally every tool is placing its files in almost random place in target directory. It will be nice to changes this black hole into something more structured. For example repository plugin is supporting only jars at the moment. I know it's brand new but it's very painful to make it more generic (if at all possible) I imagine that in future it should be possible to (that is what repository plugin will need) a) build a main project artifact (consulting) type property of POM b) know where it was stored (no artifact should be put to local repository during process). At the moment this is quite painful even for such basic use case. For that we can probably mimic the layout of local repository per project. And there is so many other places where standardization will make many things simpler. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mutliple source directories in project.xml
2cents One easy way to get around this duality between single-source and multiple source directories would be to stage out the java sources to some temporary location under ${basedir}/target for subsequent generation (back into that same directory) prior to java:compile execution. Then, these generation tools would look in the ${basedir}/target/staged-source directory for their input, and would output to the same directory...maybe all in a preGoal of java:compile or something... /2cents -john On Thu, 2004-01-08 at 14:32, Michal Maczka wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 9:43 AM To: 'Maven Users List' Subject: Mutliple source directories in project.xml Hi all I've seen that there has been a discussion regarding this before (at least on the mailing list). I gather one can circumvent this by modifying the appropriate property/variable in a preGoal (like maven.compile.src.set), but that would add to the maintenance workload and really it'd just be a hack. So my question is; will support for multiple source directories in the POM ever be incuded, or is it absolutely out of the question? Chances for that are very low! [off topic] In reality there is quite often more than one java source directory. Recently I have a pleasure to work with a few tools which are generating java code (e.g. javacc). I can perfectly understand the frustration of people trying to do the same thing and knowing maven worst then me. Even if generated source become visible for java compiler plugin, javadoc plugin is not seeing them. ( it uses ant:fileset dir=${pom.build.sourceDirectory}) I think we can do and we should do something to make those things simpler. Most of plugins which are generating java source like antlr, xdoclet, hibernate are changing ant classpath which is processed by java:compile goal. I think that this strategy is not perfect as it's breaks encapsulation of plugins and exposes their implementation details. Such process should be based on some simple contracts which give a freedom how plugins are implemented (e.g. ant should not be necessary for javac:compile goal) The solution could be very simple: every source generator can put its files into the well known place (e.g. target/generated/java ). then javac, javadoc and whatever else can do simple check if such directory exists and behave appropriately. Generally every tool is placing its files in almost random place in target directory. It will be nice to changes this black hole into something more structured. For example repository plugin is supporting only jars at the moment. I know it's brand new but it's very painful to make it more generic (if at all possible) I imagine that in future it should be possible to (that is what repository plugin will need) a) build a main project artifact (consulting) type property of POM b) know where it was stored (no artifact should be put to local repository during process). At the moment this is quite painful even for such basic use case. For that we can probably mimic the layout of local repository per project. And there is so many other places where standardization will make many things simpler. 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: Mutliple source directories in project.xml
On Thu, 2004-01-08 at 16:25, John Casey wrote: 2cents One easy way to get around this duality between single-source and multiple source directories would be to stage out the java sources to some temporary location under ${basedir}/target for subsequent generation (back into that same directory) prior to java:compile execution. Then, these generation tools would look in the ${basedir}/target/staged-source directory for their input, and would output to the same directory...maybe all in a preGoal of java:compile or something... /2cents Do you think that could be a standard? Something we could add to the POM? I think it might be useful ... build generateSourcesDirectory/ /build Something all the tools like Antlr, JavaCC, XDoclet, etc. could use. -john On Thu, 2004-01-08 at 14:32, Michal Maczka wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 9:43 AM To: 'Maven Users List' Subject: Mutliple source directories in project.xml Hi all I've seen that there has been a discussion regarding this before (at least on the mailing list). I gather one can circumvent this by modifying the appropriate property/variable in a preGoal (like maven.compile.src.set), but that would add to the maintenance workload and really it'd just be a hack. So my question is; will support for multiple source directories in the POM ever be incuded, or is it absolutely out of the question? Chances for that are very low! [off topic] In reality there is quite often more than one java source directory. Recently I have a pleasure to work with a few tools which are generating java code (e.g. javacc). I can perfectly understand the frustration of people trying to do the same thing and knowing maven worst then me. Even if generated source become visible for java compiler plugin, javadoc plugin is not seeing them. ( it uses ant:fileset dir=${pom.build.sourceDirectory}) I think we can do and we should do something to make those things simpler. Most of plugins which are generating java source like antlr, xdoclet, hibernate are changing ant classpath which is processed by java:compile goal. I think that this strategy is not perfect as it's breaks encapsulation of plugins and exposes their implementation details. Such process should be based on some simple contracts which give a freedom how plugins are implemented (e.g. ant should not be necessary for javac:compile goal) The solution could be very simple: every source generator can put its files into the well known place (e.g. target/generated/java ). then javac, javadoc and whatever else can do simple check if such directory exists and behave appropriately. Generally every tool is placing its files in almost random place in target directory. It will be nice to changes this black hole into something more structured. For example repository plugin is supporting only jars at the moment. I know it's brand new but it's very painful to make it more generic (if at all possible) I imagine that in future it should be possible to (that is what repository plugin will need) a) build a main project artifact (consulting) type property of POM b) know where it was stored (no artifact should be put to local repository during process). At the moment this is quite painful even for such basic use case. For that we can probably mimic the layout of local repository per project. And there is so many other places where standardization will make many things simpler. 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] -- 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: Mutliple source directories in project.xml
Now, in an amazing magic trick, I'll contradict myself! :) contradiction The only potential problem I see is the case where two generation tools expect pristine, untweaked sources...then, you have a sort of pseudo race condition, where success dependends upon the ordering of generator execution... /contradiction -john On Thu, 2004-01-08 at 16:38, Jason van Zyl wrote: On Thu, 2004-01-08 at 16:25, John Casey wrote: 2cents One easy way to get around this duality between single-source and multiple source directories would be to stage out the java sources to some temporary location under ${basedir}/target for subsequent generation (back into that same directory) prior to java:compile execution. Then, these generation tools would look in the ${basedir}/target/staged-source directory for their input, and would output to the same directory...maybe all in a preGoal of java:compile or something... /2cents Do you think that could be a standard? Something we could add to the POM? I think it might be useful ... build generateSourcesDirectory/ /build Something all the tools like Antlr, JavaCC, XDoclet, etc. could use. -john On Thu, 2004-01-08 at 14:32, Michal Maczka wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 9:43 AM To: 'Maven Users List' Subject: Mutliple source directories in project.xml Hi all I've seen that there has been a discussion regarding this before (at least on the mailing list). I gather one can circumvent this by modifying the appropriate property/variable in a preGoal (like maven.compile.src.set), but that would add to the maintenance workload and really it'd just be a hack. So my question is; will support for multiple source directories in the POM ever be incuded, or is it absolutely out of the question? Chances for that are very low! [off topic] In reality there is quite often more than one java source directory. Recently I have a pleasure to work with a few tools which are generating java code (e.g. javacc). I can perfectly understand the frustration of people trying to do the same thing and knowing maven worst then me. Even if generated source become visible for java compiler plugin, javadoc plugin is not seeing them. ( it uses ant:fileset dir=${pom.build.sourceDirectory}) I think we can do and we should do something to make those things simpler. Most of plugins which are generating java source like antlr, xdoclet, hibernate are changing ant classpath which is processed by java:compile goal. I think that this strategy is not perfect as it's breaks encapsulation of plugins and exposes their implementation details. Such process should be based on some simple contracts which give a freedom how plugins are implemented (e.g. ant should not be necessary for javac:compile goal) The solution could be very simple: every source generator can put its files into the well known place (e.g. target/generated/java ). then javac, javadoc and whatever else can do simple check if such directory exists and behave appropriately. Generally every tool is placing its files in almost random place in target directory. It will be nice to changes this black hole into something more structured. For example repository plugin is supporting only jars at the moment. I know it's brand new but it's very painful to make it more generic (if at all possible) I imagine that in future it should be possible to (that is what repository plugin will need) a) build a main project artifact (consulting) type property of POM b) know where it was stored (no artifact should be put to local repository during process). At the moment this is quite painful even for such basic use case. For that we can probably mimic the layout of local repository per project. And there is so many other places where standardization will make many things simpler. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mutliple source directories in project.xml
On Thu, 2004-01-08 at 16:42, John Casey wrote: Now, in an amazing magic trick, I'll contradict myself! :) contradiction The only potential problem I see is the case where two generation tools expect pristine, untweaked sources...then, you have a sort of pseudo race condition, where success dependends upon the ordering of generator execution... /contradiction The pre/post goals are executed in the order they are registered so would this really be a problem? -john On Thu, 2004-01-08 at 16:38, Jason van Zyl wrote: On Thu, 2004-01-08 at 16:25, John Casey wrote: 2cents One easy way to get around this duality between single-source and multiple source directories would be to stage out the java sources to some temporary location under ${basedir}/target for subsequent generation (back into that same directory) prior to java:compile execution. Then, these generation tools would look in the ${basedir}/target/staged-source directory for their input, and would output to the same directory...maybe all in a preGoal of java:compile or something... /2cents Do you think that could be a standard? Something we could add to the POM? I think it might be useful ... build generateSourcesDirectory/ /build Something all the tools like Antlr, JavaCC, XDoclet, etc. could use. -john On Thu, 2004-01-08 at 14:32, Michal Maczka wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 9:43 AM To: 'Maven Users List' Subject: Mutliple source directories in project.xml Hi all I've seen that there has been a discussion regarding this before (at least on the mailing list). I gather one can circumvent this by modifying the appropriate property/variable in a preGoal (like maven.compile.src.set), but that would add to the maintenance workload and really it'd just be a hack. So my question is; will support for multiple source directories in the POM ever be incuded, or is it absolutely out of the question? Chances for that are very low! [off topic] In reality there is quite often more than one java source directory. Recently I have a pleasure to work with a few tools which are generating java code (e.g. javacc). I can perfectly understand the frustration of people trying to do the same thing and knowing maven worst then me. Even if generated source become visible for java compiler plugin, javadoc plugin is not seeing them. ( it uses ant:fileset dir=${pom.build.sourceDirectory}) I think we can do and we should do something to make those things simpler. Most of plugins which are generating java source like antlr, xdoclet, hibernate are changing ant classpath which is processed by java:compile goal. I think that this strategy is not perfect as it's breaks encapsulation of plugins and exposes their implementation details. Such process should be based on some simple contracts which give a freedom how plugins are implemented (e.g. ant should not be necessary for javac:compile goal) The solution could be very simple: every source generator can put its files into the well known place (e.g. target/generated/java ). then javac, javadoc and whatever else can do simple check if such directory exists and behave appropriately. Generally every tool is placing its files in almost random place in target directory. It will be nice to changes this black hole into something more structured. For example repository plugin is supporting only jars at the moment. I know it's brand new but it's very painful to make it more generic (if at all possible) I imagine that in future it should be possible to (that is what repository plugin will need) a) build a main project artifact (consulting) type property of POM b) know where it was stored (no artifact should be put to local repository during process). At the moment this is quite painful even for such basic use case. For that we can probably mimic the layout of local repository per project. And there is so many other places where standardization will make many things simpler. 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] - To unsubscribe, e-mail: [EMAIL
RE: Mutliple source directories in project.xml
On Thu, 2004-01-08 at 16:57, Steve Garcia wrote: What about specifying sourceDirectory as a fileset? This would add a lot more work to retrofit plugins but it really would give developers good flexibility. sourceDirectory include name=dir1 / include name=dir2 / include name=dir3 / /sourceDirectory Absolutely never going to happen. With that you've just made everything to do with sources an order of magnitude more difficult which means maven internals and all the plugins. -- 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: Mutliple source directories in project.xml
On 2004-01-08 22:38, Jason van Zyl wrote: On Thu, 2004-01-08 at 16:25, John Casey wrote: 2cents One easy way to get around this duality between single-source and multiple source directories would be to stage out the java sources to some temporary location under ${basedir}/target for subsequent generation (back into that same directory) prior to java:compile execution. Then, these generation tools would look in the ${basedir}/target/staged-source directory for their input, and would output to the same directory...maybe all in a preGoal of java:compile or something... /2cents Do you think that could be a standard? Something we could add to the POM? I think it might be useful ... build generateSourcesDirectory/ /build Something all the tools like Antlr, JavaCC, XDoclet, etc. could use. Where I may vote for this? :) Seems like a solution to problem that many people raised. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mutliple source directories in project.xml
What about specifying sourceDirectory as a fileset? This would add a lot more work to retrofit plugins but it really would give developers good flexibility. sourceDirectory include name=dir1 / include name=dir2 / include name=dir3 / /sourceDirectory Absolutely never going to happen. With that you've just made everything to do with sources an order of magnitude more difficult which means maven internals and all the plugins. Well...I'm not surprised to hear that. I think generatedSourceDirectory sounds OK but would like to hear from more people who use extensively use code generation in their projects. I'm sure Maven will hear stories about how that strategy is not compatible for various reasons. Would the java plugin compile sourceDirectory first then generatesSourceDirectory second? Well it would presumably occur at the same time. Other plugins that require access to a source directory would need to be tweaked to accept two directories. For some like java:compile and I think javadoc I think that's OK. What each individual plugin could do though is make their own private Ant fileset from sourceDirectory and generatedSourceDirectory if they are unable to process multiple source directories. This would never be visible to the core Maven model or to other plugins for that matter. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mutliple source directories in project.xml
I believe it would only compile sourceDirectory if generatedSourceDirectory didn't exist... As for the serial generator execution, the only real problem I see is _what_ a particular generator would attach to as a preGoal. I mean, it might depend upon whether xDoclet, javaCC, antlr, etc. was running, and in a dynamic (unguessable) set of circumstances for different projects, I'm not sure how to get consistent behavior from these generators when they're used as maven plugins...when they're used as custom add-ons within the maven.xml, then it's a no-brainer. -j On Thu, 2004-01-08 at 17:16, Steve Garcia wrote: What about specifying sourceDirectory as a fileset? This would add a lot more work to retrofit plugins but it really would give developers good flexibility. sourceDirectory include name=dir1 / include name=dir2 / include name=dir3 / /sourceDirectory Absolutely never going to happen. With that you've just made everything to do with sources an order of magnitude more difficult which means maven internals and all the plugins. Well...I'm not surprised to hear that. I think generatedSourceDirectory sounds OK but would like to hear from more people who use extensively use code generation in their projects. I'm sure Maven will hear stories about how that strategy is not compatible for various reasons. Would the java plugin compile sourceDirectory first then generatesSourceDirectory second? Well it would presumably occur at the same time. Other plugins that require access to a source directory would need to be tweaked to accept two directories. For some like java:compile and I think javadoc I think that's OK. What each individual plugin could do though is make their own private Ant fileset from sourceDirectory and generatedSourceDirectory if they are unable to process multiple source directories. This would never be visible to the core Maven model or to other plugins for that matter. -- 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] - 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: Mutliple source directories in project.xml
On Thu, 2004-01-08 at 17:16, Steve Garcia wrote: What about specifying sourceDirectory as a fileset? This would add a lot more work to retrofit plugins but it really would give developers good flexibility. sourceDirectory include name=dir1 / include name=dir2 / include name=dir3 / /sourceDirectory Absolutely never going to happen. With that you've just made everything to do with sources an order of magnitude more difficult which means maven internals and all the plugins. Well...I'm not surprised to hear that. I think generatedSourceDirectory sounds OK but would like to hear from more people who use extensively use code generation in their projects. I'm sure Maven will hear stories about how that strategy is not compatible for various reasons. Would the java plugin compile sourceDirectory first then generatesSourceDirectory second? Well it would presumably occur at the same time. Other plugins that require access to a source directory would need to be tweaked to accept two directories. For some like java:compile and I think javadoc I think that's OK. There is only one sourceDirectory/ but what happens internally is that we track a source directory set which takes into account additional sources primarily resulting from generation. So if you look at the Antlr plugin is generates the sources before java:compile and then adds the sources it generates to the internal source directory set. Plugins have access to this source directory set. What each individual plugin could do though is make their own private Ant fileset from sourceDirectory and generatedSourceDirectory if they are unable to process multiple source directories. This would never be visible to the core Maven model or to other plugins for that matter. Plugins that operate on sources should typically deal with the internal source set which is currently the Ant reference of maven.compile.src.set. So you could generate some sources using Antlr and then run xdoclet on the maven.compile.src.set and it would operate on the all the sources, static and generated. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Mutliple source directories in project.xml
On Thu, 2004-01-08 at 17:14, Tomasz Pik wrote: On 2004-01-08 22:38, Jason van Zyl wrote: On Thu, 2004-01-08 at 16:25, John Casey wrote: 2cents One easy way to get around this duality between single-source and multiple source directories would be to stage out the java sources to some temporary location under ${basedir}/target for subsequent generation (back into that same directory) prior to java:compile execution. Then, these generation tools would look in the ${basedir}/target/staged-source directory for their input, and would output to the same directory...maybe all in a preGoal of java:compile or something... /2cents Do you think that could be a standard? Something we could add to the POM? I think it might be useful ... build generateSourcesDirectory/ /build Something all the tools like Antlr, JavaCC, XDoclet, etc. could use. Where I may vote for this? :) Seems like a solution to problem that many people raised. The 'model-additions' component in the Maven Jira project: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidepid=10030sorter/order=DESCsorter/field=priorityresolutionIds=-1component=10070 Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Mutliple source directories in project.xml
On Thu, 2004-01-08 at 17:16, Steve Garcia wrote: [ snip ] Would the java plugin compile sourceDirectory first then generatesSourceDirectory second? Well it would presumably occur at the same time. Other plugins that require access to a source directory would need to be tweaked to accept two directories. For some like java:compile and I think javadoc I think that's OK. There is only one sourceDirectory/ but what happens internally is that we track a source directory set which takes into account additional sources primarily resulting from generation. So if you look at the Antlr plugin is generates the sources before java:compile and then adds the sources it generates to the internal source directory set. Plugins have access to this source directory set. What each individual plugin could do though is make their own private Ant fileset from sourceDirectory and generatedSourceDirectory if they are unable to process multiple source directories. This would never be visible to the core Maven model or to other plugins for that matter. Plugins that operate on sources should typically deal with the internal source set which is currently the Ant reference of maven.compile.src.set. So you could generate some sources using Antlr and then run xdoclet on the maven.compile.src.set and it would operate on the all the sources, static and generated. Fantastic. Then it sounds like adding generatedSourceDirectory to the POM should be a fairly easy task. This would amount to adding that directory to the maven.compile.src.set Ant reference? I think this sounds completely reasonable and while it may not help out every project that extensively uses code generation it would help many projects. The specific semantics I'm still in the blue (re: what John Casey wrote previous in this thread where Maven would only compile sourceDirectory if generatedSourceDirectory didn't exist. Maybe I didn't understand what he wrote and I'll reread his emails again. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mutliple source directories in project.xml
On Thu, 2004-01-08 at 00:43, [EMAIL PROTECTED] wrote: I gather one can circumvent this by modifying the appropriate property/variable in a preGoal (like maven.compile.src.set), but that would add to the maintenance workload and really it'd just be a hack. For those of us who haven't been on the list long, where is this hack? I just grabbed some WSDL to generate classes and am in the same boat. Changing maven.compile.src.set didn't seem to do anything. For those interested, a repeat? Keith So my question is; will support for multiple source directories in the POM ever be incuded, or is it absolutely out of the question? Regard, Jan-Helge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mutliple source directories in project.xml
On Thu, 2004-01-08 at 18:17, Keith Irwin wrote: On Thu, 2004-01-08 at 00:43, [EMAIL PROTECTED] wrote: I gather one can circumvent this by modifying the appropriate property/variable in a preGoal (like maven.compile.src.set), but that would add to the maintenance workload and really it'd just be a hack. For those of us who haven't been on the list long, where is this hack? I just grabbed some WSDL to generate classes and am in the same boat. Nevermind: preGoal name=java:compile ant:path id=maven.compile.src.set ant:pathelement location=src/java/ ant:pathelement location=src/generated/ /ant:path /preGoal seems to work. Changing maven.compile.src.set didn't seem to do anything. For those interested, a repeat? Keith So my question is; will support for multiple source directories in the POM ever be incuded, or is it absolutely out of the question? Regard, Jan-Helge - 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: Mutliple source directories in project.xml
It may be better to use maven:addPath rather than override maven.compile.src.set - not too sure of the implications, but have a look at the plugin.jelly for plugins that generate java source - eg. antlr, castor or xdoclet. They all have something like ant:path id=some.reference.id location=${some.generated.src.dir}/ maven:addPath id=maven.compile.src.set refid=some.reference.id/ I've used this notation myself with some success. cheers, Matt Keith Irwin wrote: On Thu, 2004-01-08 at 18:17, Keith Irwin wrote: On Thu, 2004-01-08 at 00:43, [EMAIL PROTECTED] wrote: I gather one can circumvent this by modifying the appropriate property/variable in a preGoal (like maven.compile.src.set), but that would add to the maintenance workload and really it'd just be a hack. For those of us who haven't been on the list long, where is this hack? I just grabbed some WSDL to generate classes and am in the same boat. Nevermind: preGoal name=java:compile ant:path id=maven.compile.src.set ant:pathelement location=src/java/ ant:pathelement location=src/generated/ /ant:path /preGoal seems to work. Changing maven.compile.src.set didn't seem to do anything. For those interested, a repeat? Keith So my question is; will support for multiple source directories in the POM ever be incuded, or is it absolutely out of the question? Regard, Jan-Helge - 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]