On 2009-11-27, at 4:32 PM, Stephen Connolly wrote:
Sent from my [rhymes with tryPod] ;-)
On 27 Nov 2009, at 21:03, Jason van Zyl <ja...@maven.org> wrote:
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.
I presume there is _some_ leeway with the performance... 5-10% or so
and certainly no worse than 2.x
adding any logic is going to have at least 10ms of a performance
hit... so I guessy question is where is the cut-off point at which
you scream -1 on adding that implementation of that feature?
Any single feature at this point that causes more then a 5% hit is
questionable. It's always a balance of what you're gaining and how
much it costs. There are still lots of things to be optimized, but I
would release 3.0 without the profiles.xml as most people are probably
not going to adopt during 3.0 and so if there's mass hysteria we can
think about putting it 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
---------------------------------------------------------------------
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
