I've read MNG-624, and quite a bit of the code, and I feel like I
understand the algorithm relatively well. What I'm having trouble
understanding is why it needs to be so complex and look for versions in
so many places (like resolving system properties in the parent section,
etc.). IMO we need to be very careful with things like cli arguments
here, since it could have a huge impact on build reproducibility.
Ralph Goers wrote:
John, that's not a problem. I'll be happy to put something up on the
wiki in the next day or two. The code was actually much simpler in the
beginning, but as usual when I started testing things got a little more
complicated. For reference, if you haven't read MNG-624 and its many
cousins you should take a look at them.
Ralph
John Casey wrote:
Hi Ralph,
As with all of the feature branch work we've done recently (in the
last year or two), it would be extremely helpful if we could get a
write-up in the form of a proposal out on the wiki. Most importantly,
to try and address the specific use cases this design is intended to
address, and how. Also, within what assumptions the code is designed
to work, so we might talk about how it could/should fall apart when
the user violates one of those assumptions.
I'm looking through the code right now, but from my own experience
with Maven, it's simply not enough going forward to keep throwing test
cases at the code and hope we haven't missed anything. I'd like to
have a basis for writing up the new feature on the public website, to
explain it to users...this will help me understand it better, too.
I know we're somewhat in the early stages of development for this
stuff - assuming we're going to enter a stabilizing mode in the next
few weeks for what should become a GA release if everything follows
its current trajectory - but personally I'm not comfortable marking
this feature for inclusion in that release until I know more about it.
I'm in the middle of reading the code, but IMO we really need some
design documentation laying out clearly the need for the feature, and
the reasoning behind the apparent complexity of your implementation, etc.
IMO we need to have these sorts of discussions before we decide to
include any new feature in a release. I'm working on reviewing the
full list I've suggested in the original email on this thread, so I'm
sure this won't be the last request like this to the list...
Thanks,
-john
Ralph Goers wrote:
I am OK with this.
You may or may not have noticed but I created branch
maven-2.1.x-MNG-624 last night. It contains the fix for MNG-624. I
have created integration tests but haven't committed them yet. I will
soon. Before committing these to the 2.1.x branch I'd really like
folks to try it out.
This change will have a minor impact on existing projects. If you
don't specify the artifact's groupId or versionId (i.e. it is
inherited from the parent) then a new pom.xml should get created in
the target directory that has those fields filled in. That file will
be the one that is installed or deployed.
I'm only trying to resolve the parent version. I could try to resolve
the parent groupId and artifactId and some of the problem reports
mention those but I just couldn't think of a reason why they
shouldn't be specified or why someone would want them in a variable.
The version is obtained by
1. Resolving any variables provided via system properties (variables
from parents won't be found since the parent isn't known.
2. Looking in the file cache for the resolved parent project using
the relative location as the key.
3. Looking for the parent at the relative path on disk.
a. The target directory at the relative path is inspected for a
modified pom.
b. The project at the relative path is used.
If at the end of this a resolved parent version is not located throw
an Exception. Do not try to recurse to further parents.
You'll notice the comment about looking for the modified pom in the
target directory. As part of this fix the parent version, and the
project's artifactId, groupId and version are all interpolated. If
any of those fields were missing or had variables in them in the
original pom then the pom is modified and written to the target
directory. Thus, any pom that is installed or deployed will always
have these fields resolved.
In looking through the plugins it looked to me that the Eclipse and
Invoker plugins are trying to locate the base directory by calling
project.getFile().getParentFile(). These will need to be changed to
project.getBasedir() since the location of the pom might now be in a
different place and project.getFile().getParentFile() might return
the target directory instead of the base directory.
As we agreed Maven 2.1 will require Java 5. The pom has been changed
to reflect that and quite a bit of the new code uses it.
Please test and provide feedback.
Ralph
John Casey wrote:
Hi everyone,
So, it seems that we're all in agreement about the rough outline for
2.1.x and beyond. I've renamed the current RC branch to be
2.1.0-M1-RC to make this the first milestone toward some
as-yet-undetermined feature list for 2.1.0.
So, let's talk about that feature list. From earlier comments, I've
gathered that the following may be good targets to include for 2.1.0:
- Dan's reactor changes
- Parallel downloads
- PGP stuff
- MNG-624 and related issues/feature enhancements (parent
versioning, right?)
What I don't know is what state of maturity each of these is in, and
on what timeline they can be stabilized. Do the relevant developers
have enough time to finish implementing, testing, and documenting
each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so?
Maybe a better approach would be to try for a new milestone release
that contains the final result of each new feature (with latent
parts of the rest, as we work on them), such that the 2.1.0 GA will
contain all the new features in their complete forms, with any
regressions identified fixed and incorporated?
I haven't found the pertinent Confluence pages describing the above
features yet...maybe they don't exist or maybe I haven't looked hard
enough yet, but we'll need to collect the list somewhere that we can
make it public going forward, and then publish that release plan URL
on the Maven site.
Are there other things that we can fit into this sort of timeframe?
Is this too much? It's my strong preference that we try to cap this
release cycle at two months, so I guess this means taking the list
of "nearly there" features and determining whether we'll have the
time to stabilize them for inclusion, given our current availability.
Of course, once we settle the 2.1.0 release plan, we can start
talking about what we're going to do for 2.2, 2.3, etc. As long as
we keep things rolling, there's no reason anyone needs to feel
overly rushed about getting a particular feature in a particular
release...it should NOT be your only chance. :-)
What does anyone else think?
-john
---------------------------------------------------------------------
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]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
