On 2009-11-27, at 3:48 PM, Robert Scholte wrote:
With the alpha releases of Maven 3 published we'll see how
developers react
on this issue.
I've introduced Maven during several projects and my experience is
that
newbies fear the settings.xml. They let a pro setup their
settings.xml for
the repository and from that moment on it's an avoided territory.
My experience does not match with yours. In most places I'm in the
developers are not afraid of the tools they use on a daily basis, and
the number of customizations that need to be made are relatively few.
This means that the personal project-settings shall be resolved in the
pom.xml. One profile entry per developer if I'm pessimistic. Ok, maybe
combined with a filter-file it's somehow acceptable, but that requires
variables in your pom for everything a developer wants to modify
personal.
From an architectural point of view I can imagine that the
profiles.xml is
somehow a strange mechanism. But from a developers point of view
(Jason, I
read your articles about Paving the desire lines) I believe it's a
strong
concept. It just gives you the force on the right spot, personalize
the
project/pom at your own risk.
Let's see some other responses and maybe we could reanimate the
profiles.xml
Anyone can work with new model builder and add the support back in if
they like. My only requirements are the ITs passing and the
performance remains the same. Aside from that there's nothing stopping
anyone from putting the support back in.
cheers,
Robert
Bugzilla from mkle...@gmail.com wrote:
On Fri, Nov 27, 2009 at 1:59 PM, Jason van Zyl <ja...@maven.org>
wrote:
On 2009-11-27, at 7:45 AM, Milos Kleint wrote:
On Fri, Nov 27, 2009 at 12:57 PM, Jason van Zyl <ja...@maven.org>
wrote:
On 2009-11-27, at 5:55 AM, Milos Kleint wrote:
I agree with Robert here.
removal of profiles.xml file leaves maven with no non-sharable,
per-project
configuration option. I"ve added my example to
the issue http://jira.codehaus.org/browse/MNG-4060.
It would be doable with settings.xml but it would be uber-
cumbersome
to
do
so.
Why?
I think an activator for a gav would work nicely.
if there is such a thing, yes, it would help. But then after each
release,
you have to tinker with the activators.
Then just G:A would do the trick.
...unless you decide to work on a code branch with different settings
then.
Milos
It could partly work, but only when you work on one set of
projects
only, or keep on switching the settings file and have a
separate copy
for
each project (or set of projects).
The profiles.xml made the internals extremely convoluted and
hard to
test.
Most of the use cases I've seen are resolved by settings.xml and
that
can
be
made to be more intelligent to actually scope the profile in
settings.xml
to
a specific project would effectively be the same thing, or the
project
needed to be decomposed into smaller projects.
I'm fine with profiles.xml but you'll need to do the work to
integrate
that
back into the project builder and build up the integration
tests. I'm
not
interested in this work as I honestly don't think it's
necessary. There
are
tests enough there to catch anything so you can do the work and
know if
you've disturbed any other part of the system so you should be
good to
go
if
you want to add this support back in.
Which just translates to "no". fair enough.
Not at all. It means I'm not interested in that feature. So yes that
might
translate into it's unlikely Benjamin, myself or Igor aren't going
to
work
on it but there's nothing stopping you from adding the support. As
long
as
all the ITs pass and the performance doesn't degrade have at it.
Milos
Milos
On Thu, Jun 25, 2009 at 8:14 PM, Robert Scholte
<rfscho...@codehaus.org
wrote:
I didn't say it's not possible without profiles.xml, but
without it
you
have
to make a choice between the best of the worst.
Let's stick to the passwords. You don't want to expose them in
the
pom.xml,
right?
But what if project A en project B both have a ${password} in
their
pom.xml,
from the settings.xml you can't figure out which password to
use,
UNLESS
you
have to keep settings the specific profile per project. Not
really
nice.
But let me reverse the question. Why was the profiles.xml
introduced
and
what made it the team to say goodbye to this file?
Robert
BRIAN FOX-5 wrote:
Well, the mixin support should cover the profiles.xml and
more....even
better it should be possible to resolve the mixins from the
repository
which
means they are versioned and deployed artifacts like everything
else.
On Wed, Jun 24, 2009 at 11:41 AM, Robert Scholte
<rfscho...@codehaus.org>wrote:
In the settings.xml it's not possible to activate a profile by
project.
Then
again: I believe settings.xml are actually maven-settings
and not
project-settings. For most users it's a big step to dive
into the
settings.xml. For them there are only a few reasons to
access the
settings
file:
- to setup a proxy repository like nexus (which is often
done by a
more
experienced user)
- to set username+pw for a specific server.
If they don't have to touch the file then leave it, 'cause
changes
here
might break maven.
And a user-specific project-profile has to be located on a
very
logic
and
easy to access location, so the best option is next to the pom I
guess.
-regards,
Robert Scholte
BRIAN FOX-5 wrote:
Why not just put those values into the settings.xml?
On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte<
rfscho...@codehaus.org>
wrote:
I heard some time ago that the profiles.xml were removed in
Maven3.
Although I'm still using 2.1.0 I want to be prepared for
such
changes.
IMHO I think it's a bad choice to remove this option.
Maven should provide some sort of way where developers can
set/change
project properties without having to change the pom.xml.
I believe the pom should not contain developer-specific
properties
and
which can or will end up in any scm. Think of datasource-
properties.
There are three degrees of properties:
- the global properties (combined with the
activeByDefault-profile)
- profile-properties (where profiles cover multiple users.
By OS,
'stage')
- personal properties.
These personal properties can only be used with a personal
profile.
A
personal profile is the best example of data which doesn´t
belong
in
a
pom but in a separate file (and probably not in scm).
Personal properties should be somewhere close to the
project,
like
in
the
root of the project (yes, like the profiles.xml).
The both settings.xml is too far from the project and
there's no
option
in the (user's) settings.xml to set project-specific
properties.
I think that if there was a vote concerning this issue it
might
result
in
a long discussion. It's never too late for that, so let's
give it
a
try.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download
today
it's
FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/
01/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
View this message in context:
http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24190525.html
Sent from the Maven Developers mailing list archive at Nabble.com
.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
View this message in context:
http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24209431.html
Sent from the Maven Developers mailing list archive at Nabble.com
.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
View this message in context:
http://old.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p26545382.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
