maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: Maven 2.1.0 GA Plan
Date Fri, 29 Aug 2008 00:43:41 GMT
Sure. I updated the issue. I'll try to get some sample tests checked in 
as soon as I can.

Jason van Zyl wrote:
> I left some initial questions and comments in JIRA. I don't care where 
> you answer them but I would like a little more background before 
> delving into code. Primarily sample projects to see what you intend. 
> It's hard to grok entirely from your description.
> On 28-Aug-08, at 4:11 PM, 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 
>>> should NOT be your only chance. :-)
>>> What does anyone else think?
>>> -john
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message