In 2.1 practically I think it means supporting multiple versions of
the POM. Otherwise or we'll have some serious adoption problems.
People need to be able to switch over to 2.1 without changing their
POMs or there will be a hue and a cry of such enormous volume we'll
get eviscerated.
The schema will change, and we're going to have to gracefully deal
with a few versions.
On 4-Aug-08, at 12:31 AM, Ralph Goers wrote:
[EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Sun Aug 3 23:39:35 2008
New Revision: 682270
URL: http://svn.apache.org/viewvc?rev=682270&view=rev
Log:
o starting collecting the wiki, apt, and oo3 doco that has been
floating around and align it all and present a workable plan
Added:
maven/site/branches/maven-2.1-doco/
maven/site/branches/maven-2.1-doco/maven-2.1-architectural-
goals.apt (with props)
Added: maven/site/branches/maven-2.1-doco/maven-2.1-architectural-
goals.apt
URL:
http://svn.apache.org/viewvc/maven/site/branches/maven-2.1-doco/maven-2.1-architectural-goals.apt?rev=682270&view=auto
=
=
=
=
=
=
=
=
=
=====================================================================
+ * POM Changes
+ * tags/categories
+ * source: Maven, hand bombed and put in the metadata
+ * JC: What does this mean?
+ * dependency excludes && symmetry (JC: consistency?) in the
plugins
+ * terse attribute based format for the POM
+ * properties on dependencies and it was for a C build
+ * JC: What was for a C build? What do we need these
properties
+ for? If we're thinking that would be a good place to
specify
+ prefix for a C dependency, it's not a very scalable
approach...
+ * tags for dependencies being used by different plugins
+ * JC: Can we deprecate scope in favor of this, then? Or, at
+ least trim it back? It seems to me that test scope falls
into
+ the tagged-for-surefire category.
+ * JC: We should also consider tagging for plugin-execution
since
+ a single plugin could be used in multiple ways (think
surefire
+ +integration-testing)
+ * the profile for an execution environment: development versus
+ production and getting the right specification dependencies,
+ packaging problems
+ * NAR plugin
+ * JC: What does this require that we cannot support? From
+ looking at the site-plugin's effects on the lifecycle code,
+ I'm very leary of making changes to core/syntax for a
single
+ plugin...
Does this imply the XML schema will change? I would think it would
have to in order to support attributes.
Ralph
---------------------------------------------------------------------
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]
