« Return to Thread: Maven 2.1.0 GA Plan
Re: Maven 2.1.0 GA Plan
by Ralph Goers
::
Rate this Message:
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
« Return to Thread: Maven 2.1.0 GA Plan
| Free embeddable forum powered by Nabble | Forum Help |
