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]
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]
