You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Ralph Goers <Ra...@dslextreme.com> on 2008/08/04 09:31:22 UTC
Re: svn commit: r682270 - in /maven/site/branches/maven-2.1-doco:
./ maven-2.1-architectural-goals.apt
jvanzyl@apache.org 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r682270 - in /maven/site/branches/maven-2.1-doco:
./ maven-2.1-architectural-goals.apt
Posted by Ralph Goers <Ra...@dslextreme.com>.
Jason van Zyl wrote:
> 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.
>
I was actually hoping you'd say that. If the pom is open for
modification then I would really want to see a "compatible-with" section
so that a project can declare what prior versions of itself it is
compatible with and possibly at what level (i.e. api, configuration,
runtime, etc.).
I know you don't necessarily agree with this, but I consider this
absolutely necessary to make sure appropriate versions are being used.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r682270 - in /maven/site/branches/maven-2.1-doco: ./ maven-2.1-architectural-goals.apt
Posted by Jason van Zyl <ja...@maven.org>.
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:
> jvanzyl@apache.org 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org