Does Maven2 have support for Maven1 POMS (specifically Id vs ArtifactId
Inside the Maven2 repo, this pom for SLF4J 1.0 appears to be in Maven2 format: http://www.ibiblio.org/maven2/org/slf4j/slf4j-log4j12/1.0/slf4j-log4j12-1.0.pom but this one for SLF4J 1.0.1 appears to be in Maven1 format: http://www.ibiblio.org/maven2/org/slf4j/slf4j-log4j12/1.0.1/slf4j-log4j12-1.0.1.pom I'm trying to figure out if Maven2 is still capable of using the Maven1 format (I presume not, it's not legal according to the XSD), or if somebody messed up and just checked in a Maven1 format POM in the Maven 2 repo. Colin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How are people getting around the lack of custom scopes?
Thanks, I've seen that blog entry in the past, and even took part in a
discussion on maven-dev more than a year ago now.
(btw, I don't think Brett's assertion in the comments that Maven's
profiles are like Ivy's configs is accurate. Ivy's configs are much more
like configurable scopes for the most part, as the actual config names
can be transitive too, and you can pull into one config another 'x'
configs from a dependency. What _is_ nonstandardized in ivy is any set
of common config names. This is generally not an issue though for common
scopes, as the reality is that for any of your dependencies you are
generally interested only in their runtime scopes ('default' plus any
optional ones), their compile and test configs, whatever they are
called, do not need to be pulled in anyway, and certainly not
transitively, so it doesn't matter what each project calls them. The
only place you feel the lack of a convention is for pulling in sources.
It would be nice to be able to pull in sources.)
Anyway, I was hoping that after some usage of Maven2 in anger, some
people had come up with a solution to this need (a clean way to handle
optional dependencies), which is definitely there for some cases
Regards,
Colin
On 4/30/2006 12:54 PM, Eric Redmond wrote:
This is the same old debate about scope versus configuration.
Check out Xavier Hanin's blog, specifically the comments.
http://jroller.com/page/xavierhanin?entry=maven_features_comparison
I agree with you, somewhat. The ability to override a dependency in M2 is
far more verbose. In contrast, Ivy forces you configure your desired
classpath, where M2 has pre-defined scopes, and I don't want to lose that
pre-defined power. But l also like the concept of configurations,
specifically for cases like Spring. I would like to see something like
custom configurations, perhaps ID'd inclusions? In any case, most
anything
useful would require a POM change, which I wouldn't imagine would happen
soon.
Spring framework could define dependency blocks with ID.
*javax.faces*
jsf-api
jsf
Then users of Spring framework may include them:
*org.springframework*
spring-webflow
default,jsf
Eric
On 4/30/06, Colin Sampaleanu <[EMAIL PROTECTED]> wrote:
I am curious how heavy Maven2 users are getting around the lack of
custom scopes.
Profiles seem to fill the need sometimes, allowing you to produce a
module (jar file) that is specific to a particular profile, having
dependencies specific to that profile.
This assumes you are actually ok with having a separate jar file for
each profile.
But how are people handling the publishing of _one_ module which in use
may have various sets of runtime dependencies which need to be combined,
for the user of that module?
As an example, consider Spring Web Flow, published as
spring-webflow.jar. It has a set of base runtime dependencies which are
always needed. It also has some runtime dependencies that are needed
only for use with Spring MVC. It also has some runtime dependencies
which are needed only for use with Struts. And some only for JSF.
Compile time dependencies are mostly a combination of all of these, btw.
This is pretty trivial to handle with the Ivy dependency manager (used
for Spring Web Flow right now), since for a module's published
dependencies, Ivy allows you to define different 'configurations',
basically custom scopes. So a module can publish any number of
configurations, and another module depending on yours would specify any
of them they need. The config declaration for Spring Web Flow looks like
this:
This just declares the configuration names and visibility, then actual
dependencies are declared and added into one or more configs.
A project needing Spring Web Flow including the JSF capabilities would
declare that dependency as
basically it is saying, for it's own 'global' config, it needs Spring
Web Flow's 'default' and 'jsf' configs.
How are people handling this kind of need in Maven. I am not happy with
the options I see:
- use profiles: this implies publishing a separate jar for each
profile, not something I wish to do
- declare minimal dependencies and force people to manually include:
this implies that a module like spring web flow would declare only the
minimal sets of dependencies, and then users of the module would
manually add in other dependencies. This seems unacceptable.
- declare all possible dependencies and force people to manually
exclude: this implies a module like Spring Web Flow would declare all
dependencies, and then users of the module would manually exclude some
dependencies. This seems unacceptable.
There are lots of projects out there which have optional dependencies
(hibernate, etc.). Short of manual inclusions/exclusions, how are people
handling this in M
Re: How are people getting around the lack of custom scopes?
This approach is reasonable to some point, but it can start getting ridiculous too. It's a question of granularity and how far you wish to take it. There are a number of projects out there which have a lot of optional dependencies. Spring Web Flow aside, Spring Framework itself is one of them, Hibernate another, etc, and there are cases where we talk about multiple optional dependencies that may optionally be combined with each other, leading to an explosion of jars. Your suggested approach implies that library jar packaging be completely driven by dependencies used, i.e. have a one to one correlation; this is just not possible, or really desirable sometimes. Colin On 4/30/2006 12:03 PM, Arik Kfir wrote: Personally, I don't like the approach you specified. If I have a project which MIGHT use project X, Y or Z, I would expect that project to be split to four jars: project-core, project-x, project-y and project-z. The project-core would require a set of dependencies that are always needed, the project-x would require project-core (and its dependencies) along with the X dependency, and so on... I think the maven approach is far more elegant because you always know exactly what you have and what you need. just my 2 cents On 4/30/06, Colin Sampaleanu <[EMAIL PROTECTED]> wrote: I am curious how heavy Maven2 users are getting around the lack of custom scopes. Profiles seem to fill the need sometimes, allowing you to produce a module (jar file) that is specific to a particular profile, having dependencies specific to that profile. This assumes you are actually ok with having a separate jar file for each profile. But how are people handling the publishing of _one_ module which in use may have various sets of runtime dependencies which need to be combined, for the user of that module? As an example, consider Spring Web Flow, published as spring-webflow.jar. It has a set of base runtime dependencies which are always needed. It also has some runtime dependencies that are needed only for use with Spring MVC. It also has some runtime dependencies which are needed only for use with Struts. And some only for JSF. Compile time dependencies are mostly a combination of all of these, btw. This is pretty trivial to handle with the Ivy dependency manager (used for Spring Web Flow right now), since for a module's published dependencies, Ivy allows you to define different 'configurations', basically custom scopes. So a module can publish any number of configurations, and another module depending on yours would specify any of them they need. The config declaration for Spring Web Flow looks like this: This just declares the configuration names and visibility, then actual dependencies are declared and added into one or more configs. A project needing Spring Web Flow including the JSF capabilities would declare that dependency as basically it is saying, for it's own 'global' config, it needs Spring Web Flow's 'default' and 'jsf' configs. How are people handling this kind of need in Maven. I am not happy with the options I see: - use profiles: this implies publishing a separate jar for each profile, not something I wish to do - declare minimal dependencies and force people to manually include: this implies that a module like spring web flow would declare only the minimal sets of dependencies, and then users of the module would manually add in other dependencies. This seems unacceptable. - declare all possible dependencies and force people to manually exclude: this implies a module like Spring Web Flow would declare all dependencies, and then users of the module would manually exclude some dependencies. This seems unacceptable. There are lots of projects out there which have optional dependencies (hibernate, etc.). Short of manual inclusions/exclusions, how are people handling this in Maven2? Regards, Colin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- __ Cheers, Arik Kfir [EMAIL PROTECTED] Linux user, number 415067 - http://counter.li.org/ http://corleon.dnsalias.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How are people getting around the lack of custom scopes?
I am curious how heavy Maven2 users are getting around the lack of custom scopes. Profiles seem to fill the need sometimes, allowing you to produce a module (jar file) that is specific to a particular profile, having dependencies specific to that profile. This assumes you are actually ok with having a separate jar file for each profile. But how are people handling the publishing of _one_ module which in use may have various sets of runtime dependencies which need to be combined, for the user of that module? As an example, consider Spring Web Flow, published as spring-webflow.jar. It has a set of base runtime dependencies which are always needed. It also has some runtime dependencies that are needed only for use with Spring MVC. It also has some runtime dependencies which are needed only for use with Struts. And some only for JSF. Compile time dependencies are mostly a combination of all of these, btw. This is pretty trivial to handle with the Ivy dependency manager (used for Spring Web Flow right now), since for a module's published dependencies, Ivy allows you to define different 'configurations', basically custom scopes. So a module can publish any number of configurations, and another module depending on yours would specify any of them they need. The config declaration for Spring Web Flow looks like this: This just declares the configuration names and visibility, then actual dependencies are declared and added into one or more configs. A project needing Spring Web Flow including the JSF capabilities would declare that dependency as basically it is saying, for it's own 'global' config, it needs Spring Web Flow's 'default' and 'jsf' configs. How are people handling this kind of need in Maven. I am not happy with the options I see: - use profiles: this implies publishing a separate jar for each profile, not something I wish to do - declare minimal dependencies and force people to manually include: this implies that a module like spring web flow would declare only the minimal sets of dependencies, and then users of the module would manually add in other dependencies. This seems unacceptable. - declare all possible dependencies and force people to manually exclude: this implies a module like Spring Web Flow would declare all dependencies, and then users of the module would manually exclude some dependencies. This seems unacceptable. There are lots of projects out there which have optional dependencies (hibernate, etc.). Short of manual inclusions/exclusions, how are people handling this in Maven2? Regards, Colin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Is there any way to override the default filter pattern for resources?
Carlos,
It's not just JSPs first of all. ${} is a pretty common syntax used
for various templating and expression evaluation needs. For example, you
might see that in a Spring application context file when somebody uses
PropertyPlaceHolderConfigurer to externalize some values to a separate
properties files. Or OSWorkFlow uses it to evaluate expressions in
workflow definitions. There are lots of other cases...
So there's a conflict here. There's a general need to do filtering while
you build, and I've certainly worked on plenty of projects in the past
where we filtered the entire set of JSPs (or whatever the templates
were), and pretty well all non-class files in the app since in ant at
least (and Maven may be just as efficient) you didn't pay a huge penalty
for copying with filtering.
As for the use cases for filtering during the build, we're talking about
having different dev/staging/production profiles, or very lightweight
'branding' type changes that don't warrant entirely different template
files, etc. So this is is things like properties files with JDBC
properties, server addresses, etc. It's also JSP/template pages for the
web site, and the web.xml file. It applies to various lib specific xml
files.
Given the need, I just consider it completely unacceptable
(irresponsible really) to rely on luck that tokens used for build-time
filtering will not conflict with the same tokens used by some run time
(post build-time) system or library that uses the same ${xxx} syntax.
It's a complete non-issue with ant, as you can pick whatever token
replacement syntax you need.
Colin
On 4/29/2006 7:54 PM, Carlos Sanchez wrote:
Colin, can you explain what's the use case here?
I don't see the probelm with JSPs because you would at most filter the
web.xml setting a parameter that is later accessed at runtime from the
jsps. I can't think about a use case where you would need to filter
all the jsps at build time.
On 4/29/06, Colin Sampaleanu <[EMAIL PROTECTED]> wrote:
Hi,
When turning on filtering for resources in Maven2, is there any way to
override the default filter string pattern of '${token}'? I can't find
any mention of any way to customize this, in any docs.
The use of ${token} as a token is IMHO a really bad choice, given the
fact that it's such a common token replacement syntax in various page
templating technologies like JSPs. These are exactly the kinds of files
likely to be copied around as resources, leading to all sorts of
potential conflicts in filter instances meant to be replaced by Maven,
and instances meant for the JSP engine.
Regards,
Colin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Is there any way to override the default filter pattern for resources?
Wayne,
This is not really true any longer, as of this fix:
http://jira.codehaus.org/browse/MWAR-12
you can filter with the WAR task too.
In any case, I was making a general point about conflicting with
application template files of any sort (not just JSPs) that use the
${} syntax. It's a very common syntax...
Regards,
Colin
On 4/29/2006 4:56 PM, Wayne Fay wrote:
JSP files etc are not "resources" but rather should be stored in the
/src/main/webapp folder and thus not processed as "resources".
So I'll disagree with your statement. And I have no idea how/where to
modify the "default filter string pattern" if it is even possible.
Wayne
On 4/29/06, Colin Sampaleanu <[EMAIL PROTECTED]> wrote:
Hi,
When turning on filtering for resources in Maven2, is there any way to
override the default filter string pattern of '${token}'? I can't find
any mention of any way to customize this, in any docs.
The use of ${token} as a token is IMHO a really bad choice, given the
fact that it's such a common token replacement syntax in various page
templating technologies like JSPs. These are exactly the kinds of files
likely to be copied around as resources, leading to all sorts of
potential conflicts in filter instances meant to be replaced by Maven,
and instances meant for the JSP engine.
Regards,
Colin
-
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: [m2] Is there any way to override the default filter pattern for resources?
On 4/29/2006 4:55 PM, Simon Kitching wrote:
On Sat, 2006-04-29 at 16:09 -0400, Colin Sampaleanu wrote:
Hi,
When turning on filtering for resources in Maven2, is there any way to
override the default filter string pattern of '${token}'? I can't find
any mention of any way to customize this, in any docs.
The use of ${token} as a token is IMHO a really bad choice, given the
fact that it's such a common token replacement syntax in various page
templating technologies like JSPs. These are exactly the kinds of files
likely to be copied around as resources, leading to all sorts of
potential conflicts in filter instances meant to be replaced by Maven,
and instances meant for the JSP engine.
Well, I believe that any tokens not recognised will be left unchanged.
So if you ensure non-conflicting names are used for those tokens you
want to substitute during builds, eg
${buildtime.username}
instead of
${username}
won't this achieve what you want?
Simon,
Unfortunately this is just way too unpredictable. We're talking about
mixing up the tokens from Maven with those from any other templating
technology used in resources that are being copied. Somebody can for
example come along, add a variable that is used during the build, and
then kill a similarily named substitution variable in a template file of
some sort that is used at runtime in the app, and you won't even
necessarilly find out about it until later.
To compound the potential for problems, there are plenty of maven tokens
which are not very distinctly maven-specific, i.e. they don't have any
sort of unique prefix.
There really needs to be a way to force a syntax which is exclusive to
Maven's use... I find it really hard to believe that nobody else has not
seen this as an issue in the past. I've always done lots of ant
filtering in the past in my ant buils, and made sure that I used a token
syntax that didn't conflict with any sort of filtering inside any app
template files.
Colin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Is there any way to override the default filter pattern for resources?
Hi,
When turning on filtering for resources in Maven2, is there any way to
override the default filter string pattern of '${token}'? I can't find
any mention of any way to customize this, in any docs.
The use of ${token} as a token is IMHO a really bad choice, given the
fact that it's such a common token replacement syntax in various page
templating technologies like JSPs. These are exactly the kinds of files
likely to be copied around as resources, leading to all sorts of
potential conflicts in filter instances meant to be replaced by Maven,
and instances meant for the JSP engine.
Regards,
Colin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven xdoclet
The maven xdoclet plugin is huge because it is actually generated (as part of the xdoclet build). I personally find it generally useless. For anything more than the simpler cases, it is easier and cleaner to have 'ant-style' xdoclet definitions in maven.xml exactly as you would have used in an ant build project. Having to use flat properties in build.properties can get a lot more verbose and error prone than a clean hierarchical xml definition in maven.xml. On top of that, there were some bugs (upper vs. lowercase property names, which don't matter in xml files but do matter for properties), and some properties which were wrong. I believe most of them are fixed by now in xdoclet CVS but at a minimum you would have to rebuild xdoclet 1.2post-beta3. You can search the archives for this mailing list for some messages from me showing how you would use xdoclet in maven.xml. khote wrote: I'm insufficiently familiar with xdoclet, I'm looking for a "hook" to get myself into it. in fact I know maven better than I know ant ... have become somewhat familiar with the jelly scripting from looking at the plugin.jelly in the plugins. The xdoclet plugin is huge compared to all the others, approx 11,000 lines of code. I was hoping that a good way to do it would be to use webdoclet to help me generate a struts-config, this would show me how to set things up in maven.xml and build/project.properties, which preGoal and/or postGoal events I should program to, when and where, that kind of thing. I'm using ant copy-filters comfortably in building a war subproject whose artifact is a dependency in an ear subproject, it appears to me that xdoclet in this frame of mind is a similar thing, only a great deal smarter. I have jmx working for me comfortably, getting this WAR deployed, scm, scp, cvs .. all that stuff. What should I put in an Action I'm writing, for example, to have webdoclet write information to the struts-config? How do I set this up in maven.xml? Are there any webdoclet or other *doclet processes which can help me with struts tiles? I'm convinced that I want to use xdoclet when I start implementing the "uber project" with ejbs and jboss and jmx and all that ... deployment xmls up the wazoo so to speak. - Original Message - From: "tek1" <[EMAIL PROTECTED]> To: "Maven Users List" <[EMAIL PROTECTED]> Sent: Sunday, September 21, 2003 1:28 AM Subject: Re: maven xdoclet Did you look at this yet? http://xdoclet.sourceforge.net/maven-plugin.html If you're familiar with the basics of XDoclet and Maven, the above offers a good explanation of integrating the two. After reading and trying the above, let us know if you have any questions. At 22:44 03/09/20 -0700, you wrote: Looking for online tutorials covering maven and xdoclet, webdoclet, that kind of thing. Anybody know of any? K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any way to have shared properties when extending from a base project
Actaully, I like your method a bit better, since I want to have a
top-level build.properties, but still allow a build.properties in the
project to override that if possible. Since I have a maven.xml in every
subproject anyways, it's not that big a deal to read in some files there.
Only issue is triggering the read. There used to be a build start goal
(forgot what the name was) that you could use to attach off of (with a
postGoal), but it got broken a long long time ago. I forgot the exact
name. Does anybody know if this goal is still non-existentbroken? I had
a look in Jira, but couldn't find an issue. Without that goal, it's
almost impossible to do something at the begining of every build (like
readin in properties) when you don't know what goal the user will be
running, so you can do a preGoal off that or one of its dependencies...
Colin
khote wrote:
this method works? I'm going to give it a try for certain.
It sounds a little chicken-and-the-egg though does the top-level
maven.xml copy the *.properties into the sub-projects, or do the
sub-projects copy from ../*.properties themselves?
- Original Message -
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: "'Maven Users List'" <[EMAIL PROTECTED]>
Sent: Friday, September 19, 2003 11:35 AM
Subject: RE: Any way to have shared properties when extending from a base
project
Hi Colin,
This is a known wanted feature (I also want it dearly). Check JIRA. It's
scheduled for 1.1. If you want it faster, please send a patch and I'll
gladly apply it :-)
As a workaround on my work project, we have a custom maven.xml goal that
copies the top level project.properties to the current project you're
building. That means of course that you have to put all properties at
the top level.
Thanks
-Vincent
-Original Message-
From: Colin Sampaleanu [mailto:[EMAIL PROTECTED]
Sent: 19 September 2003 20:30
To: Maven Users List
Subject: Any way to have shared properties when extending from a base
project
I just realized that while you can extend a project with something
like
extend>${basedir}/../master/project.xml
maven doesn't seem to read in build.properties (and project.properties
either I guess) from the master project. This is a real PITA, as I
don't
want to force people to put identical build.properties files in all
the
subprojects, and it's not acceptible to have a build.properties file
in
the user directory, as it will trample the version for other projects.
I think I'm missing something, as this is a big hole. What are other
people doing in this situation?
Regards,
Colin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Any way to have shared properties when extending from a base project
I just realized that while you can extend a project with something like
extend>${basedir}/../master/project.xml
maven doesn't seem to read in build.properties (and project.properties
either I guess) from the master project. This is a real PITA, as I don't
want to force people to put identical build.properties files in all the
subprojects, and it's not acceptible to have a build.properties file in
the user directory, as it will trample the version for other projects.
I think I'm missing something, as this is a big hole. What are other
people doing in this situation?
Regards,
Colin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using file://../../path for maven.repo.remote
You can definitely use file: references to set up remote repos. I use
this definition for maven.repo.remote in some projects:
maven.repo.remote=\
file:${basedir}/../../shared/repository,\
http://www.ibiblio.com/maven
Try using 'file:' instead of 'file://', the latter is not really kosher.
Also, you probably need to go relative off ${basedir}.
However, note that there are some _severe_ issues with repo overrides
and plugins. Plugins don't seem to be able to pick up remote and local
repo overrides from a project's property files. This is why when I do my
builds, all the dependencies the plugins themselves need come from
ibiblio, and only my own dependencies come from my filesystem remote
repo. Even then, everything totally breaks when I use the multiproject
plugin, as it gets even more confused.
This issue is incredibly annoying and makes maven unusable in a number
of situations... I filed a bug report about 7-8 months ago about this,
but the functionality is still broken, and unfortunately I've not had
the time to fix it myself, which has prevented me from moving a bunch of
stuff to maven...
Robles, Rogelio wrote:
I need to support a closed building/deployment environment because the
production releases are built and deployed by our SCM admin team. They use a
clean and closed build box, using only officially approved tools: jdk, ant
and soon Maven ;-).
'remote' repositories are stored in our SCM server and project stakeholders
(developers and SCM admin team) get them through snapshots when is worth to
do it.
The structure that I have is this:
/root
/
/projectX
/component1
/component2
/component3
/thirdparty
/maven
/repo
/internal
/repo
As you can see the is different for all the stakeholders of
the project so I can't use hard coded absolute directory names for the
repositories location. Then I use relative URLs for references:
In component1's project.properties file I have:
maven.repo.remote=file://../../thirdparty/maven/repo,
file://../../internal/repo
This produces:
Attempting to download commons-lang-1.0.1.jar.
WARNING: Failed to download commons-lang-1.0.1.jar.
And I don't get the artifacts installed in my local repository.
At the beginning I was under the impression that I can't use relative URLs,
but I tested moving the 'remote' repositories as siblings of my components,
under projectX, and everything works fine, with this:
maven.repo.remote=file://../thirdparty/maven/repo, file://../internal/repo
Is there a possible solution for this static properties-file-only solution?
do I need to create a dynamic solution? I have thought of instead of
relative URL's generate absolute URLS at runtime using jelly, is this
possible?
Rogelio
-
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: Using file://../../path for maven.repo.remote
Don't bother posting into Jira, it's already posted as Maven-224. I also discovered the bit with removing the /repository causing the subsequent ClassNotFoundException. I think it's due to the fact that plugin dependencies are assumed to have been satisfied once plugins have been initialized the first time. I believe there may be a Jira entry for this. Robles, Rogelio wrote: Under this circumstances, relative file URLs, Maven is unable to supply jar dependencies to its plugins. I'm using the jar:install goal in my component, and the first plugin to be loaded it seems that is maven-artifact-plugin-1.0-SNAPSHOT and Maven couldn't find its dependencies. If I use an absolute file URL for maven.repo.remote everything works fine, but I cannot use this as a solution since other developers will have different SCM work directories. In other things I found the following, if I erase the "/repository" directory from my local repository I get a java.lang.ClassNotFoundException: velocity at the middle of the jar dependencies copying, if I run maven again, everything works fine :-\. I erased that directory when I was trying to have a new local repository but just the jar files. I don't know if this new or not, I'll post it into JIRA anyway. Rogelio -Original Message- From: Robles, Rogelio [mailto:[EMAIL PROTECTED] -Original Message- From: Colin Sampaleanu [mailto:[EMAIL PROTECTED] However, note that there are some _severe_ issues with repo overrides and plugins. Plugins don't seem to be able to pick up remote and local repo overrides from a project's property files. Yes, now I'm stuck at the same place as you (I'm using maven-beta-10), some plugins dependencies are not being copied over from the remote repositories. I need to find out which plugins are and how they are getting their dependencies. - 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: Using file://../../path for maven.repo.remote
It's Maven-224.
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-224
I would have attempted a fix myself, but my feeling is that this
involves potentially fairly heavy duty changes, more than my limited
knowledge of Maven internals allows me to tackle...
[EMAIL PROTECTED] wrote:
Colin,
which is the bug report?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Colin Sampaleanu <[EMAIL PROTECTED]> wrote on 12/08/2003 10:48:37 PM:
You can definitely use file: references to set up remote repos. I use
this definition for maven.repo.remote in some projects:
maven.repo.remote=\
file:${basedir}/../../shared/repository,\
http://www.ibiblio.com/maven
Try using 'file:' instead of 'file://', the latter is not really kosher.
Also, you probably need to go relative off ${basedir}.
However, note that there are some _severe_ issues with repo overrides
and plugins. Plugins don't seem to be able to pick up remote and local
repo overrides from a project's property files. This is why when I do my
builds, all the dependencies the plugins themselves need come from
ibiblio, and only my own dependencies come from my filesystem remote
repo. Even then, everything totally breaks when I use the multiproject
plugin, as it gets even more confused.
This issue is incredibly annoying and makes maven unusable in a number
of situations... I filed a bug report about 7-8 months ago about this,
but the functionality is still broken, and unfortunately I've not had
the time to fix it myself, which has prevented me from moving a bunch of
stuff to maven...
Robles, Rogelio wrote:
I need to support a closed building/deployment environment because the
production releases are built and deployed by our SCM admin team. They
use a
clean and closed build box, using only officially approved tools: jdk,
ant
and soon Maven ;-).
'remote' repositories are stored in our SCM server and project
stakeholders
(developers and SCM admin team) get them through snapshots when is
worth to
do it.
The structure that I have is this:
/root
/
/projectX
/component1
/component2
/component3
/thirdparty
/maven
/repo
/internal
/repo
As you can see the is different for all the stakeholders
of
the project so I can't use hard coded absolute directory names for the
repositories location. Then I use relative URLs for references:
In component1's project.properties file I have:
maven.repo.remote=file://../../thirdparty/maven/repo,
file://../../internal/repo
This produces:
Attempting to download commons-lang-1.0.1.jar.
WARNING: Failed to download commons-lang-1.0.1.jar.
And I don't get the artifacts installed in my local repository.
At the beginning I was under the impression that I can't use relative
URLs,
but I tested moving the 'remote' repositories as siblings of my
components,
under projectX, and everything works fine, with this:
maven.repo.remote=file://../thirdparty/maven/repo,
file://../internal/repo
Is there a possible solution for this static properties-file-only
solution?
do I need to create a dynamic solution? I have thought of instead of
relative URL's generate absolute URLS at runtime using jelly, is this
possible?
Rogelio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Noob question: how to deal with non maven jars?
You can do something like this in maven.xml:
file="${basedir}/lib/core/xmltypes.jar"
tofile="${jardir__}/${pom.artifactId}-xmltypes-${pom.currentVersion}.jar"
overwrite="true"
/>
However, whether this is a good idea is another question. In this case,
the jar in question is manually generated from stuff in this project, so
it makes some sense. But if it is just another jar that is in the local
lib dir which is really standalone, and it is not on ibiblio, then you
are probably better off defining another remote repo which is actually
local (alongside ibiblio), and put the jar there. E.g. in the
project.properties:
# override remote repo since we want to also point to a cvs based remote
repo
# to get some jars not found at ibiblio
maven.repo.remote=\
file:${basedir}/../../shared/repository,\
http://www.ibiblio.com/maven
Regards,
Colin
Michael Mills wrote:
After spending a lot of time looking at (what little) documentation
there is and trying out various maven command lines I was wondering how
(other than manually creating the dir in the maven.local.repository) you
get any old jar that is required for a build into your local repository.
If I have a jar: bob.jar that is currently in the 'lib' folder of my
project, which is currently using ant to build with that path added to
my project.classpath, how do I get bob.jar into my local repository so
that I can add the following to my maven project.xml file and get it to
compile:
bob
bob
1.0
jar
I have tried to use the "maven jar:xxx" goals but they don't seem to
work, also "maven repository:xxx" don't work (I have got a local
webserver running and maven.repo.remote=http://localhost stored in
build.properties in the user.profile directory).
I would have thought that you could cd to the lib folder and execute a
maven command to register bob in the local repository as version 1.0?
This does not seem possible.
In general I guess I am asking: what process is intended for files that
A, are not open source (i.e. in the standard maven remote repo) or B, do
not have the associated src files (and hence can not be built by a maven
project where you can use "maven jar:install").
-Mike
-
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: MAVEN_RC1_STABLE branch
Are you expecting that this will be merged back into HEAD, or HEAD merged into this in the future? Unfortuntately I think your chance of merging 2 diverged branches (where ongoing work has gone on in both) with CVS is next to nil. What is probably more realistic is for Jason or whoever to do his refactor on the stable branch (on his machine only), and while he is refactoring keep updating with checkins to this branch so he is basically tracking the branch, and then check in the refactor when it actually works... [EMAIL PROTECTED] wrote: As you may have noticed, the MAVEN_RC1_STABLE branch is now open for business. I've backported the fixes post the RC1 refactor tag, so it should all be up to date. The goal is to keep this a functioning set of code and apply fixes to it until the refactor is ready to be dropped in. As such, all non-core work should happen in this branch. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ant filterchain support on copying
Can anybody think of a way to make Maven support use of ant filterchains when copying resources, short of completely overriding the resource copying code? I don't think there is any way, but maybe somebody has an idea... We find filterchains like with the ant copy task extremely useful, since we don't have to manually create the filters; basically all the ant properties get expanded as filters. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Has Some Nice Features, But...
If you are doing mostly C/C++ with some Java, you might want to look at SCons. It's _way_better thank makefiles, and now has some knowledge of Java, although nothing on the level of Maven. Presumably you could have SCons call out to Maven or Ant for more complicated Java work. http://www.scons.org/ Brian Hall wrote: How does Maven handle a mixed development world? How easy (if it can be done at all) is it for Maven's features be used to manage a project that contains Java, C/C++, tcl/tk, etc.? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Removing ${pom.X} usage in properties files.
Jason van Zyl wrote:
On Tue, 2003-06-17 at 11:37, Jason van Zyl wrote:
Hi,
I wanted to check with users about the frequency of using ${pom.X}
notation in properties files. I would like to remove this feature as it
is causing some grief internally and the only place I see it being used
internally is driver.properties which isn't visible to most users.
I don't believe this 'feature' is being used but I wanted to check
because I believe I made an error in judgement letting this usage into
existence.
So for example in driver.properties we have:
maven.final.name = ${pom.artifactId}-${pom.currentVersion}
This is the type of usage I want to remove.
Just a clarification: there seem to be a few places in plugins where the
${pom.X) interpolation is used and I can catch those to make sure things
work. I really just wanted to know if this feature is in widespread use.
I would really like to move to properties files that strictly contain
user defined values and not pom defined values.
I've used it once in a while, to do stuff like
maven.ejb.final.name=${pom.artifactId}-beans-${pom.currentVersion}
Now this was to get around a limitation of the ejb plugin, which can't
(or couldn't) let you override the final name. It would not necessarilly
be that big a deal if this went away, I suppose, as long as I could
still acess the value in maven.xml///
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: setting maven.repo.local property for all projects
There is another bug related to the repo override which I reported a
long time ago
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-224
and I don't think has been fixed. Effectively, repo overrides don't work
as far as plugins are concerned. Not necessarilly much of an issue for
the plugins which ship with maven, since all their dependencies are on
iBiblio, but a problem for adding in your own plugins.
Brett Porter wrote:
Its user's home (Java's ${user.home}).
Unfortunately, Cygwin doesn't figure that out properly, so you have to
put it under Window's HOME. If you do echo %HOME% in cmd.exe, you'll see
it is probably "C:\Documents And Settings\tek1".
I might investigate this and either have cygwin do a translation of the
HOME variable, or specify user.home on the command line.
You can probably bypass all of this for now and do
export MAVEN_OPTS=-Duser.home=`cygpath -pw /home/tek1`, then put
build.properties in there.
Cheers,
Brett
On Fri, 2003-06-13 at 15:50, tek1 wrote:
Hi Brett.
Thanks for your reply.
Is $HOME the user's home directory or MAVEN_HOME?
I tried placing build.properties in MAVEN_HOME as well as my user home
directory (I'm using Cygwin on Win2k, so my home directory is
"/cygwin/home/tek1").
However, neither setting worked...
Please advise.
Thank you again and have a nice evening.
At 15:10 03/06/13 +1000, you wrote:
put it in $HOME/build.properties instead. (this is in the same section -
showing it takes precedence).
I think driver.properties is now inside maven.jar and not loaded from
bin/. I'll submit a patch to the doco.
Cheers,
Brett
On Fri, 2003-06-13 at 14:13, tek1 wrote:
Hello.
According to the Maven Setup instructions:
"http://maven.apache.org/reference/user-guide.html#Maven Setup"
it seems as though if I set:
maven.repo.local=/java/jars
in
MAVEN_HOME/bin/driver.properties
that all projects would use the local repository at "/java/jars".
Even though I changed this setting, it doesn't seem to take effect.
Maven's still looking for the default local repository...?
I'm using maven-1.0-beta9.
Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter <[EMAIL PROTECTED]>
f2 network
-
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: eclipse subprojects
It's a bit of a hack in that ideally you would nest the projects, but it should work fine, although you might have to work on the reactor setup a bit so you don't include your root. The main issue with using Eclipse in similr scenarios is when you get handed a maven or ant based nested structure (root with subs underneath), and you can't rearrange stuff like this. Then you have to go to something like putting the eclipse metadata for the root somewhere else, then linking back to any source in the root project. Sonnek, Ryan wrote: Thank you both for your replies. So, I'm basically hearing two different approaches, one to create a subproject of the root project (something like subroot), and place the project.xml, maven.xml, etc there. The other option would be to map all subprojects into one eclipse project. I personally think that mapping all the source directories into one project defeats the purpose of having the subprojects in the first place. My current project is relatively small, but having 10-20 subprojects does not seem uncommon. Having projects broken apart so that developers can focus on their own modules and not have to see all other java and test files is a major development bonus. I can imagine having this master project easily having 20 different src directories, and now THAT would be a maintenance nightmare. Placing the root files in a subproject seems to be a pretty good idea. Will the Reactor still perform as it should? This is the project layout that you're suggesting right? +MyProject |--+common subproject |--project.xml (extends ../root subproject/project.xml) |--maven.xml |--+ejb subproject |--project.xml (extends ../root subproject/project.xml) |--maven.xml |--+root subproject |--project.xml (main project.xml defining dependencies, etc) |--maven.xml so, no files exist outside of a subproject? Does this seem like a good solution or more of a hack? Ryan -Original Message- From: Gilles Dodinet [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 10:14 AM To: Maven Users List Subject: Re: eclipse subprojects your layout makes me think you need to have one and only one eclipse project (say root), with several source directories (common/src/java, ejb/src/java, etc..). maven-new module illustrates that. The drawback of such an approach is that .classpath isnot easily generated since maven-eclipse-plugin doesnt yet take such layout into consideration. another approch would be to have different eclipse projects (so common module should not be under root) but then the problem is that you break the semantical relationships that exist between the various subprojects. -- gd Sonnek, Ryan wrote: Ack! I've just switched my project over to maven and have broken it up into several subprojects (ejb, common, war, etc). now, I know this is not a "maven" problem, but as this is a common layout for a maven project I hope someone will be able to help. i've been able to create my subprojects within eclipse, but I cannot get the files from my project root (ie: project.xml, maven.xml, etc) to be included. I've tried creating a new project for the root module, but eclipse throws an error saying that "project root and project root/common overlap." Is there some other way to get these files included into eclipse? I need to have these files tracked by cvs, and eclipse is my main cvs tool. Any help would be greatly appreciated! Here's my project layout: +--project root |--+common module |--project.xml |--maven.xml |--+ejb module |--project.xml |--maven.xml |--project.xml |--maven.xml I hope someone can answer this one! Ryan - 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: eclipse subprojects
This is a problem, because while Eclipse can handle nested sources via exclusion filters, it can't actually handle nested projects where you need to have the eclipse project metadata somewhere at a root level, and below that have eclipse project metadata for other projects. Now what will work is putting the root project metadata somewhere else. So it can live parallel to the subprojects for example, and then you can use links to bring in the source it needs... Sonnek, Ryan wrote: Ack! I've just switched my project over to maven and have broken it up into several subprojects (ejb, common, war, etc). now, I know this is not a "maven" problem, but as this is a common layout for a maven project I hope someone will be able to help. i've been able to create my subprojects within eclipse, but I cannot get the files from my project root (ie: project.xml, maven.xml, etc) to be included. I've tried creating a new project for the root module, but eclipse throws an error saying that "project root and project root/common overlap." Is there some other way to get these files included into eclipse? I need to have these files tracked by cvs, and eclipse is my main cvs tool. Any help would be greatly appreciated! Here's my project layout: +--project root |--+common module |--project.xml |--maven.xml |--+ejb module |--project.xml |--maven.xml |--project.xml |--maven.xml I hope someone can answer this one! Ryan - 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: werkz or jeez documetation
btw, maven plugins can be found in the plugins dir underneath the local repository location... Colin Sampaleanu wrote: I see what you are getting at. The maven docs which mention goals in maven.xml http://maven.apache.org/reference/user-guide.html#maven.xml are basically not giving any info, and they refere you to jelly tag docs which don't have any info on the werkz tags themselves. Your best bet at this point is just to take a look at some of the maven.xml files for some of the maven plugins, which usually exercise goals pretty much. There is actually not a lot to it, basically you define goals, preGoals (which will get executed before the goal specified as the "name" attribute, and postGoals, which get executed afterwards. So if you want to for example have some code of yours in maven.xml execute before the built-in java:compile goal, you would define something like this in maven.xml ...some code Hope this helps... Neil Blue wrote: Thanks Colin, What I was looking for was some information on what goals are and how to write them. As far as I understand, in order to add project specific functionality to maven I need to add goals in a similar way as I added targets in ant. Cheers Neil Colin Sampaleanu wrote: You can find some werkz documentation here: http://werkz.werken.com/ although you normally shouldn't have to understand werkz that much if all you want to do is use maven (as opposed to hacking it). Neil Blue wrote: Hello, I am trying to get started with Maven, but I can't find any documentation on werkz or jeez. Please can anyone tell me if any is available. - 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: werkz or jeez documetation
I see what you are getting at. The maven docs which mention goals in maven.xml http://maven.apache.org/reference/user-guide.html#maven.xml are basically not giving any info, and they refere you to jelly tag docs which don't have any info on the werkz tags themselves. Your best bet at this point is just to take a look at some of the maven.xml files for some of the maven plugins, which usually exercise goals pretty much. There is actually not a lot to it, basically you define goals, preGoals (which will get executed before the goal specified as the "name" attribute, and postGoals, which get executed afterwards. So if you want to for example have some code of yours in maven.xml execute before the built-in java:compile goal, you would define something like this in maven.xml ...some code Hope this helps... Neil Blue wrote: Thanks Colin, What I was looking for was some information on what goals are and how to write them. As far as I understand, in order to add project specific functionality to maven I need to add goals in a similar way as I added targets in ant. Cheers Neil Colin Sampaleanu wrote: You can find some werkz documentation here: http://werkz.werken.com/ although you normally shouldn't have to understand werkz that much if all you want to do is use maven (as opposed to hacking it). Neil Blue wrote: Hello, I am trying to get started with Maven, but I can't find any documentation on werkz or jeez. Please can anyone tell me if any is available. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: werkz or jeez documetation
You can find some werkz documentation here: http://werkz.werken.com/ although you normally shouldn't have to understand werkz that much if all you want to do is use maven (as opposed to hacking it). Neil Blue wrote: Hello, I am trying to get started with Maven, but I can't find any documentation on werkz or jeez. Please can anyone tell me if any is available. Thanks Neil - 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: Why no multiple locations of sources? ( was Re: inter-projectdependencies for the Eclipse plugin )
Jason van Zyl wrote: On Wed, 2003-04-02 at 09:05, Rafal Krzewski wrote: Jason van Zyl wrote: That is distinctly different than multiple source directories for your application. And here we are trying satisfy these requirements and scale by letting the plugins deal with these different requirements instead of trying to jam everything into the POM. I believe that the POM is the proper place for defining what goes in your project. Plugins should retrieve information from there and proceed with their work. I've pondered this many a time. I really do not like the idea of having to augment your POM when you choose to use a plugin. I very much like the way the antlr plugin works in that it just kicks in when certain resources are present. Right now many plugins rely on project.properties file rather than POM, wich I think is not right. Of course we should always use our best judgement to avoid cluttering the POM, but I thing that the source directories (java, aspect, unit test, and others that arise) are crucial for defining the project, and therefore they should be in the POM. I really like Michal's proposal with sources/source/type elements. It puts the emphasis on the plugins undestating a specific type of sources, and allows us remove funcitonality from Maven core - it only manages information on abstract source sets. Sorry but I'm not sure I follow. Adding this abstraction adds to maven's core. Offloading all processing and definition to the plugin is the way I want to move. I think this kind of change that it's really worth pursuing. I'm not really in favour of this and much prefer the way the antlr plugin works. I would like to see most of the element removed and replaced with a place where you can define plugin settings if they are required. We started this a long time ago and there was a proposal that just never got implemented. I completely agree with you about having plugins actually be the ones doing their stuff with the sources. However, maven has to provide basic facilities to plugins for dealing with source directories, and for expressing these in the POM (in a section specific to that plugin is fine). What feels inherently wrong about the present setup is that the POM specifically knows about 4 different source directory types, and stops there. It should really only know about 'source directories', and stop there. What is done with the directories is a function of metadata (not expressed as xml elements, as presently done) attached to those entries, or the fact thay they are in a plugin specific section, and various plugins which act on that. Something similar to Michal's proposal is actually a lot cleaner than the present setup. Regards, Colin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inter-project dependencies for the Eclipse plugin
Jason van Zyl wrote: On Tue, 2003-04-01 at 10:33, Colin Sampaleanu wrote: Jason, can you clarify what the real issue with multiple source directories is? ... Given that Maven already does support multiple source dirs in the only fashion I use them (to separate test sources from non-test sources), and handles generated sources (from the like of xdoclet), I don't personally need anything more for my projects. Multiple source directories are not supported. The addPath tag is being abused if people are not using it in conjunction with some generative process and it will just eventually bite them in the ass. Make their projects many fold more complex than they have to be, developer comprehension will drop an order of magnitude and it's generally a lose/lose situation. However this restriction seems like a somewhat arbitrary decision notheless, Far from arbitrary. People can use the addPath tag to work around it and to migrate projects but I certainly don't recommend it ever. At least in the POM more than one source directory will never be supported. I don't understand how you can say Maven doesn't support multiple source directories, what about sourceDirectory, unitTestSourceDirectory, integrationUnitTestSourceDirectory, aspectSourceDirectory? These are all different source directories that are handled by various parts of Maven. To draw the line there seems awfully presumptious. With all due respect to your opinion (that this handles most cases and results in good practices, which I agree), I've been around the block enough to know that I don't know everything. If somebody/an organization has a need to add another source dir that is on an equal basis to the ones above (to be used by a plugin, or whatever), and feel that in their usage this results in a cleaner/better setup, power to them. Unfortunately there is no way to do it. Is Maven development driven by the needs of the users, or the need to enforce your (and in this case mine) idea of best practices at the exclusion of others. If it were a matter of compromising the best way to do it, or introducing large amounts of additional complexity to the setup/build process, I would understand it, but that is not the case here. This attittude should apply in general, not just to this feature. Just my opinion, and I hope I don't come off the wrong way here, I do in general love Maven and what you've done. Regards, Colin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inter-project dependencies for the Eclipse plugin
Jason van Zyl wrote: On Mon, 2003-03-31 at 19:29, [EMAIL PROTECTED] wrote: "Mark H. Wilkinson" <[EMAIL PROTECTED]> wrote on 01/04/2003 01:44:01 AM: On Fri, 2003-03-28 at 20:57, Mark McBride wrote: Ahh; see what you mean. I don't think it would be that difficult to add support for that kind of thing, but it's not there now. You'd need to solve a couple of problems: 1. You need a standard way to represent multiple Java source trees in the POM. That will never happen. It was fully intentional that there is only one source directory per project. At the moment the paths to the source trees are encoded in the jelly script, so aren't easily available to any plugin. A simple solution that you could start with would be to put them in elements in the POM, but there probably ought to be support for this in the POM itself (IMHO). Sorry, I don't understand. Do you mean for multiple source directories when you add them manually? The addPath tag was made specifically for generative plugins like antlr where sources are generated. That is the only intended use. We've tried having multiple source trees before. It was damn difficult. I'm happy for someone else to give it a go and get everything working consistently, but I personally have been down that road and never want to go back. +1 There will never, ever, ever be support for more than one source tree per project. Jason, can you clarify what the real issue with multiple source directories is? I've tried searching through the dev and user archives I've got (back to last Aug), and couldn't get a good idea of what the problem is. The best I could find was a statement from you that you don't consider it good form since it encourages putting together unrelated source in the same project. While having Maven encourage good source organization practices is a laudible goal, are there any real technical issues with supporting multiple source directories? Given that Maven already does support multiple source dirs in the only fashion I use them (to separate test sources from non-test sources), and handles generated sources (from the like of xdoclet), I don't personally need anything more for my projects. However this restriction seems like a somewhat arbitrary decision notheless, which makes it much harder for some projects currently using Ant or various IDEs like JBuilder or Eclipse, all of which do currently support multiple source directories (and multiple target directories for that matter), to switch over to Maven. If existing projects must be significantly reorganized to use Maven, there is much less chance they will do so, as opposed to the approach of getting the build going in some fashion, and then doing a gradual refactoring of the project layout(s). IMHO, the best tools are flexible enough to support existing practices, while gently prodding users towards best practices. Regards, Colin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
