On 10-Aug-08, at 2:25 PM, Ralph Goers wrote:
That is all OK, but I'd really like to see a 2.1 that allows more to
be done on the 2.0.x branch than we are currently comfortable with.
That's the plan that people have been suggesting and what I refer to
as the intermediary bridge i.e. the next mild step to 2.1.x from
2.0.x. Where the trunk goes to 3.0.x.
Nothing as revolutionary as what is in trunk, but with some ability
to fix some problems that might not be completely compatible. The
bugs I am currently looking at - MNG-624, MNG-2446, MNG-2971 and
MNG-3267 are examples of this. 624 is actually pretty easy and I
have code that has no compatiblity problems and is actually pretty
simple. But it is still an enhancement.
Sure, do that on 2.1.x (as we now seem to be calling it). I don't see
any problem with that.
The other issues identify a problem that is a little harder to fix
only because I haven't figured out how it could be done without
being incompatible, even if what is currently happening - deploying
poms with a variable in the version element - is just wrong.
Not necessarily. A property referring to a profile activated on a
particular platform where it was expected to be evaluated during the
build would cause a problem. I don't think it's as straight forward as
interpolating prior to deployment. This is part of the overall process
we need a spec for. This is not a very concrete answer but there are
probably a range of things that can safely be interpolated and
probably make sense, any properties associated with profiles activate
by OS, JDK, or some other ad-hoc property referring to an environment
will probably cause problems. Should people do this, probably not. But
we never told them not to. Then how to you categorize what's allowed
and what's not. No idea.
I think Brian wanted to cut from 2.0.9 instead of 2.0.10 but you guys
should go for it. We just need to make sure the integration tests
actually mean something so when I try to match capabilities with a
potentially different implementation/solution it don't whack everyone.
Ralph
Jason van Zyl wrote:
I think having the intermediary bridge is a good idea, and I would
be comfortable finding the last stable version of trunk that works
with Mevenide and then release that and then leave that as a stable
branch for you to work off.
One of the problems is that your code seems not to be very testable
from your own description and there's nothing we could run to
validate changes in trunk haven't busted you without you manually
testing. You have to do something about that because asking you to
manually try things isn't tenable. We'll make the stable branch of
3.0.x, and then we can leave that pretty much static except for bug
fixes you want to put in there.
I need a release just as badly as you for the Eclipse IP process.
So if you we can match what you're using and find that point in
time where you're happy we'll roll back trunk to there, cut a 3.0.x
branch and you will have something stable. I want to continue
getting Mercury and Shane's new project builder in because to me
that will be a massive stabilization in the artifact mechanism and
Shane is just tearing out all sort of cruft that's built up in the
POM builder and we're just not going to be able to create a spec'd
process, mixins support, multi-format/version support, and a many
other things with these two changes.
Releasing trunk as 2.1 I think would be a very bad idea, but I'm
happy to rollback/patch to whatever point in time makes you
comfortable. I would prefer to plough along on trunk which looks
like would become 3.1.x in this scheme. You would probably stay
away from Mercury and we are really going to need a harness from
you we can run. The ITs will get better and be protection at the
CLI level but you seem to keep getting bitten at the embedder level.
Let me know what you would like to do.
On 10-Aug-08, at 10:37 AM, Milos Kleint wrote:
On Sat, Aug 9, 2008 at 11:32 AM, Mauro Talevi
<[EMAIL PROTECTED]> wrote:
Milos Kleint wrote:
please, please, let's not add anything else to trunk (2.1) and
stabilize it. I've been waiting for a stable embeddable version
for 2
years and with the number of work (complete rewrites of
everything)
in the branches, a stable maven.next looks years ahead again.
Not having an embeddable maven that works in the IDE integrations
hurts the adoption and trust of users.
Milos, isn't just a case of renaming trunk/2.1 to trunk/3 ?
well, the version number itself is of little interest to me, but I
see
a lot of people cooking new stuff at branches. I suppose the
intention
is to get this code into trunk. The question for me is wheher it
gets
into trunk before the maven.next is released or after (be it 2.1 or
3.0 ). The maven.next that's interesting to me is the version that
is
embeddable.
Also cutting an alpha or beta would enable IDE devs to work to
that without
having sleepless nights about stabilisation.
Well, if the alphas and betas get cut from a stable branch that will
ultimately become the next final release, I'm cool with it.
Milos
Cheers
---------------------------------------------------------------------
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
What matters is not ideas, but the people who have them. Good people
can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
