You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by ji...@codehaus.org on 2003/09/20 01:56:10 UTC
[jira] Created: (MAVEN-836) put projects in /multiproject/${pom.artifactId}/index.html
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-836
Here is an overview of the issue:
---------------------------------------------------------------------
Key: MAVEN-836
Summary: put projects in /multiproject/${pom.artifactId}/index.html
Type: Improvement
Status: Unassigned
Priority: Minor
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
plugin-multiproject
Versions:
1.0-beta-10
Assignee:
Reporter: joseph benavidez
Created: Fri, 19 Sep 2003 6:55 PM
Updated: Fri, 19 Sep 2003 6:55 PM
Environment: linux x86
Description:
Maybe it's just me, but I tend to put spaces in the names and not in ID's. So I'd advocate using the id as part of the url to subprojects, so that the url's don't have spaces...
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Why is build.properties from ${user.home} the most dominant
Posted by Rafal Krzewski <Ra...@caltha.pl>.
Jason van Zyl wrote:
>>I wanted to get the rationale as to why build.properties from
>>${user.home} is more dominant than build.properties and
>>project.properties from the project dir.
From my experience, it is indeed a problem when you need to make
a system specific override for a set of related projects, but
not for all the project I have in my system. A concrete example:
I have a bunch of projects in an eclipse workspace, about 5k files
in total. I run maven tasks to generate javadocs, make wars and so
on, the number of files in the workspace goes through the roof in an
instant. This slows things down, especially searching.
My solution to this was adding the following to my ~/build.properties
maven.build.dir=/home/rafal/sandbox/maven-targets/${pom.artifactId}
this way maven generated stuff does not pollute my eclipse workspace.
Unfortunately this setting makes many project other break including
Maven itself.
Obviously, I could add the above setting to the build.proprties of
each of the projects in the workspace, but this just doesn't feel
right to me. What if I decide to move the targets directory? Go through
them again and update the path? Naaah...
I wish that we could introduce an intermediate step between
~/build.properties and ${basedir}/build.properties in an organized manner.
One solution would be traversing the directory tree upwards from
${basedir} to ${user.home} and combining the build.properties files.
(a weak point - what if user builds a project outside his/her $HOME?)
I second Colin's oppinion that ${basedir}/build.properties should be
dominant as they are the most specific, and each directory's
build.properties should be dominant over it's parent, ending with
~/build.properties that are most general and thus the weakest.
Another solution that might fix things for many projects would be
inheriting build.properties from the parent project (in terms or
<extends>, not directories). It won't fix my particular problem though
as the projects in my workspace don't have a single parent project.
If the two above approaches are combined, a question remains if the
build.properties from the parent project (by extends) should be dominant
over those forom the parend directory (by file system), or the other way
around.
I think that properties combining is one of the weakest points of Maven
ATM. Especially MAVEN-37 (the longest standing bug in Maven, over a one
year old). I'm sure that this will be sorted out sooner or later, and I
don't personally care if it's pre or post 1.0 as I try to keep up with
HEAD, but I'm sure that this will confuse the hell out of people flowing
into maven after 1.0 is announced. If I were you, Brave Developers, I
would make fixing and documenting it a release blocker, for your own
sanity's sake.
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Why is build.properties from ${user.home} the most dominant
Posted by Colin Sampaleanu <co...@exis.com>.
Jason van Zyl wrote:
>On Sat, 2003-09-20 at 15:41, Colin Sampaleanu wrote:
>
>
>>I wanted to get the rationale as to why build.properties from
>>${user.home} is more dominant than build.properties and
>>project.properties from the project dir.
>>
>>
>
>To provide a final place where all values can be overridden. The
>asumption being that not many values would actually ever reside in
>~/build.properties. As Maven is project centric it is assumed that all
>values of importance are specified at the project level. Given N maven
>projects with their own project.properties how many values in your
>~/build.properties conflict with values in any of the project that use
>Maven to build?
>
>>omewhat of an unfortunate mess...
>>
>>
>
>Well, I have exactly two entries in my ~/build.properties, I have never
>had a problem and I don't recall many other complaints about the
>dominance of the properties file processing.
>
>>s there any chance I can convince
>>you guys to reverse the order?
>>
>>
>
>Not without some examples of what the problem is. What exactly are you
>having problems with?
>
>
I don't think you have much of a problem with it becuase you're using it
simply as a source of globabl overrides, and that's not a very common
occurrence.
My whole point is that as far as I can tell, more than half of the
projects using this mechanism with ant build files use it as a source of
defaults, not as a source of overrides. Now, without some sort of real
standard, the mechanism is effectively useless for both sides. If you
know that 60% of the builds are going to treat it one way, and 40% the
other, then you can't rely on it at all...
As for using ~/build.properties as a source of defaults, there's plenty
of stuff it makes sense to put in there. I've personally got a number of
entries. For example, things like a default db password for building
projects for dev use, which then get overriden as needed when building
for staging or production use, etc. Things like my username, for
inserting into build records, etc. If I want to switch to maven, these
values suddently become overrides, and I have to take them out, and
customize every project instead, or introduce another file with defaults.
As to why a '~/build.properties is defaults' approach makes more sense
than a '~/build.properties is overrides' approach, here's a list:
- in an informal look at some dozens of open source projects that I had
sitting on my filesystem, more than half used the defaults approach vs
the other way arounnd (if they looked at ~/build.properties at all)
- multilevel ant projects have very often used the mechanism of a
build.properties in the root folder, with build.properties in the
subproject roots being dominant. If you consider that ~/build.properties
is another level (or more) up from the main project root, it should have
the least dominance.
- maven already allows extending and overriding a root project.xml with
a subproject's project.xml. Now maven doesn't currently allow extending
build.properties and project.properties from a root project, but when it
does, I presume it makes sense to work the same way as for the
project.xml, the lower level project is dominant. Same argument applies
here as for ant then for ~/build.properties; it is 'farther away' from
the subproject you are in, so should be less dominant.
So my suggestion is to make ~/build.properties the _least_ dominant,
that is it would become a source of defaults, and add another file like
~/buildoverrides.properties (or whatever) which would provide overrides.
Some people would be affected, but I doubt very many; as per your email,
there is not much need of a global overrides mechanism, and because it
overrides everything, you're not likely to put much in there. Also, this
would be more in line with the way the majority of ant projects with
care about ~/build.properties treat it, so less ant projects would be
affected, and could make an easier transition to maven.
Regards,
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Why is build.properties from ${user.home} the most dominant
Posted by Jason van Zyl <jv...@maven.org>.
On Sat, 2003-09-20 at 15:41, Colin Sampaleanu wrote:
> I wanted to get the rationale as to why build.properties from
> ${user.home} is more dominant than build.properties and
> project.properties from the project dir.
To provide a final place where all values can be overridden. The
asumption being that not many values would actually ever reside in
~/build.properties. As Maven is project centric it is assumed that all
values of importance are specified at the project level. Given N maven
projects with their own project.properties how many values in your
~/build.properties conflict with values in any of the project that use
Maven to build?
> Somewhat of an unfortunate mess...
Well, I have exactly two entries in my ~/build.properties, I have never
had a problem and I don't recall many other complaints about the
dominance of the properties file processing.
> Is there any chance I can convince
> you guys to reverse the order?
Not without some examples of what the problem is. What exactly are you
having problems with?
> Regards,
> Colin
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Why is build.properties from ${user.home} the most dominant
Posted by Michal Maczka <mm...@interia.pl>.
> -----Original Message-----
> From: Rafal Krzewski [mailto:Rafal.Krzewski@caltha.pl]
> Sent: Sunday, September 21, 2003 3:43 PM
> To: Maven Developers List
> Subject: Re: Why is build.properties from ${user.home} the most dominant
>
>
> dion@multitask.com.au wrote:
>
> > The idea is that the user knows what he wants, not the project builder.
>
> I thought that the difference between project.properties and
> build.properties was the the former were created by the project's
> vendor and the latter by the person who is building the project
> and are supposed to contain machine-specific settings that should
> not be shared through an SCM system.
> Because of that it makes sense to have both project.proerties and
> build.properties in a single project directory at the same time.
> Additionally Maven allows the user to set properties in
> ~/build.properties file. Currently the settings from this file
> override the settings from project's build.properties file.
> Both of the files say what the user (project builder) wants, not the
> project vendor, it's just the matter of specificality (<- correct
> english???). The settings in project's build.propertis say what
> the user want for this particular project and thus should override
> what the user wants generally. That's why I think Colin's request
> is valid.
>
> R.
I also see this as Rafal does.
We didn't have any compliments because current processing order is forcing
users
to use ${user.home}/properties for what they are meant for: for keeping
common settings
which are shared between all project.
At the moment what you put to this file is affecting 100% of the projects.
If this is our choice - "all or nothing" - I am OK with that.
But this sometimes can be a problem.
I have once worked on project which has a content of maven.local.repo kept
in CVS and
IMHO it was wise decision in this particular case (very tight security
policy).
With the current processing order I was unable to override this property for
this particular project.
(which would be very helpful)
Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Why is build.properties from ${user.home} the most dominant
Posted by Rafal Krzewski <Ra...@caltha.pl>.
dion@multitask.com.au wrote:
> The idea is that the user knows what he wants, not the project builder.
I thought that the difference between project.properties and
build.properties was the the former were created by the project's
vendor and the latter by the person who is building the project
and are supposed to contain machine-specific settings that should
not be shared through an SCM system.
Because of that it makes sense to have both project.proerties and
build.properties in a single project directory at the same time.
Additionally Maven allows the user to set properties in
~/build.properties file. Currently the settings from this file
override the settings from project's build.properties file.
Both of the files say what the user (project builder) wants, not the
project vendor, it's just the matter of specificality (<- correct
english???). The settings in project's build.propertis say what
the user want for this particular project and thus should override
what the user wants generally. That's why I think Colin's request
is valid.
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Why is build.properties from ${user.home} the most dominant
Posted by di...@multitask.com.au.
Colin Sampaleanu <co...@exis.com> wrote on 21/09/2003 05:41:06 AM:
> I wanted to get the rationale as to why build.properties from
> ${user.home} is more dominant than build.properties and
> project.properties from the project dir.
These are the users preferences, regardless of any project properties, or
build properties for a project.
They win, regardless.
> This has always seemed ass-backwards to me, and is in fact backwards to
> the order in which a number of ant projects I've seen (and mine) always
> did it. I always use ${build.properties} in user home as a source of
> default values, which can then be overriden on a project by project
> basis, as needed. If instead ${user.home} properties are the most
> dominant, those properties can not be used as a source of any defaults
> any longer, since they would wipe out any customizations in the project
> itself.
The idea is that the user knows what he wants, not the project builder.
> Now I take it that the Maven devs have always seen
> ${user.home}/build.properties not as a source of default values, but as
> a way to override project values, but in this respect I think that
> location is almost useless, since you would override all projects on the
> system, and in any case, there exists a mechanism at the project level
> to override properties, that is, build.properties at the project level
> being dominant over propect.properties.
Yep, and user's build.properties is intended to be global.
> I took a look through various open-source projects to see how their ant
> files did it. It's interesting that you find both orders in
Remember ant properties files are different. Ant properties, once set, are
immutable.
> jakarta-commons, not very-consistent. You also find both orders in other
> projects. Generally though, from what I could see, the majority of the
> projects (if they used a build.properties from ${user.home} at all, make
> the local project one the most dominant. I also found some projects
> where the file in ${user.home} was called something else, not
> build.properties. Again, generally those values are overriden by local
> values.
>
> Somewhat of an unfortunate mess... Is there any chance I can convince
> you guys to reverse the order?
I'm very much against this.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Why is build.properties from ${user.home} the most dominant
Posted by Colin Sampaleanu <co...@exis.com>.
I wanted to get the rationale as to why build.properties from
${user.home} is more dominant than build.properties and
project.properties from the project dir.
This has always seemed ass-backwards to me, and is in fact backwards to
the order in which a number of ant projects I've seen (and mine) always
did it. I always use ${build.properties} in user home as a source of
default values, which can then be overriden on a project by project
basis, as needed. If instead ${user.home} properties are the most
dominant, those properties can not be used as a source of any defaults
any longer, since they would wipe out any customizations in the project
itself.
Now I take it that the Maven devs have always seen
${user.home}/build.properties not as a source of default values, but as
a way to override project values, but in this respect I think that
location is almost useless, since you would override all projects on the
system, and in any case, there exists a mechanism at the project level
to override properties, that is, build.properties at the project level
being dominant over propect.properties.
I took a look through various open-source projects to see how their ant
files did it. It's interesting that you find both orders in
jakarta-commons, not very-consistent. You also find both orders in other
projects. Generally though, from what I could see, the majority of the
projects (if they used a build.properties from ${user.home} at all, make
the local project one the most dominant. I also found some projects
where the file in ${user.home} was called something else, not
build.properties. Again, generally those values are overriden by local
values.
Somewhat of an unfortunate mess... Is there any chance I can convince
you guys to reverse the order?
Regards,
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org