-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Brett Porter wrote: | +1, though I have some concerns having thought more about it | | - where do we trunk/branch/etc? Well, the mojo project is probably the closest analogy to this new svn space, unless it's the plugins space on ASF. In both cases, they share a single trunk (and, implicitly, a single set of branches/tags, right?). This, in spite of the fact that each plugin is on a separate release cycle... I'm not sure what decisions led to that approach over, say, creating a trunk per plugin (ugly, I know)...but I'd think what's good for one would work for all. It would also help to maintain consistency here, IMO. So, I guess that leads me to say let's use one set of trunk/tags/branches for all of this new shared space. | - how does this impact the bootstrap? This will have the same impact on the bootstrap as any other project that the core plugins depend on, but which isn't included in the core distribution. Those projects within this shared space that are required by the core plugins will have to be included in the bootstrap. IIRC, we have maven-archiver in the bootstrap already, along with the IT verifier, etc. from the components space. Also, we're building the plugins space (mounted at ../plugins from the root of the components space). So, this doesn't represent *that* big of a change; it's just another sibling space to checkout and build. If the plugins build is contingent on the plugins being checked out, then we can extend this idea and make plugin builds contingent on the ability to build these shared projects (or the required subset, more likely). | - not sure this is a good idea for any libraries closely ties to maven | core releases. If you mean we shouldn't move maven-artifact into the shared space, I agree 100%. :-) Did you have specific concerns about some of the other projects that aren't quite so integral to Maven? | | Keeping them truely separate is probably the best alternative here. If | maven-archiver is separate then it can get new versions and stick to 2.0 | which controls what the prerequisite release of maven the plugins have. Yes, just as the plugins' specification of prerequisite maven version is going to become crucial (if it's not already), the shared projects will also have to depend on this feature. It will allow them to grow faster than the main Maven distribution. cheers, john | | Cheers, | Brett | | John Casey wrote: | | Hi, | | I noticed that this issue has stagnated on the dev list. Since Brett's | post was last and seemed to recommend a reasonable course of action, I'd | like to put it to a vote. | | The basic concept is to create a new top-level project in the Maven SVN | repository called 'maven-shared' where we can park APIs that are used by | multiple plugins, but which do not belong in a lockstep release cycle | with Maven's core. This will promote code reuse between plugins, and | should make maintaining individual plugins simpler. At the same time, it | will provide the flexibility we need to update and release these pieces | of code without releasing a new version of Maven. | | | You can find the full discussion here: | | http://marc.theaimsgroup.com/?t=113078654300003&r=1&w=2 | | I'll give the issue the customary 72 hours, then tally the results. | | Thanks, | | 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] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDg0lUK3h2CZwO/4URAvcJAJ9JIQK5XfotkLy+Er8ezPsQiVTdIQCZAdni 7POKau62+yJYFn7wIZ4coh8= =SzKA -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
