POM and maven-new

[Jason van Zyl <ja...@zenplex.com>]

Hello,

Just thought I would chime in with a few thoughts on the POM and
maven-new.

The new artifact code is meant to allow the creation of any arbitrary
production from the listed dependencies in the POM. A production can be
a:

o classpath
o set of files
o set of properties

Basically, any arbitrary collection of values that can be contained
within a set of dependencies in a POM.

Now so far I have seen the notion of <type> and <kind> discussed.

Currently in maven-new the <type> element is specifically used to
determine which artifact handler an artifact is processed with. This is
not exactly what I had in mind and it's my fault for not explaining
myself clearly while Michal was doing some refactoring.

I believe that <type> and <kind> can be replaced with a single set of
hints. And here the hints are specifically artifact handler hints.

Say we have the following POM:

<pom>
  <dependencies>
    <dependency>
      <groupId></groupId>
      <artifactId></artifactId>
      <hints>
        <type>jar</type>
        <war>true</war>
      </hints>
    </dependency>
    <dependency>
      <groupId></groupId>
      <artifactId></artifactId>
      <hints>
        <type>jar</type>
        <war>true</war>
      </hints>
    </dependency>
    <dependency>
      <groupId></groupId>
      <artifactId></artifactId>
      <hints>
        <type>jar</type>
        <test>true</test>
      </hints>
    </dependency>
  </dependencies>
</pom>

So instead of an artifact being passed through only one artifact handler
it passes through a chain of artifact handlers and each artifact handler
does what it likes with the artifact based on hinting information.

So we may have some standard artifact handlers in the core, but I see
many of the artifact handlers coming from plugins themselves. When a
plugin is loaded the artifact handlers it provides are loaded into the
artifact handler chain. When it's finished they can be removed. So for
example with the WAR plugin it would have a simple artifact handler that
looked for 'war=true' hint and if found would add that artifact to a
production which was a list of artifacts you wanted packed into a WAR.

So I see the POM being able to store an arbitrary map of productions and
it would be up to the artifact handler to name the production. So when
the artifacts are processed any number of productions can be created and
stored in the POM. When a plugin is executed it has access to the POM
and can extract the productions it needs to carry out its task.

So this way everything is offloaded to the plugin. If the standard
productions don't suit the plugin then the plugin provides 1..n artifact
handlers to create the productions it needs. And the artifact handler is
simply triggered by the hinting information.

The <hints> could also be <properties>, I don't really care. I'm just
trying to stress that a single set of hints or properties would do the
trick as all we are really trying to do is provide some arbitrary set of
information to a plugin and I believe this will work.

We could also use the hinting information to access the artifact type
directory or anything else that would be required in the artifact
processing chain.

I will actually send another message about transitive dependencies to
keep the ideas separated.

-- 
jvz.

Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: POM and maven-new

[Rafal Krzewski <Ra...@caltha.pl>]

Jason van Zyl wrote:

> We'll probably find there are more orthogonal sets of qualities as you
> put it. Whatever is more clear I'm fine with. To me the type is just
> another piece of information.

It's possible that more orthogonal qualities will show over time.
I think that it would be good to keep them visually separated in the
POM to make it more readeable to humans. I don't have strong opinion
on the internal representation though - if it's easier to keep all
the hinting information in single place it's OK with me.

>>Type determines the filename, and repository location of the artifact,
>>but does not affect the kind of processing the artifact will recieve.
> 
> Currently in maven-new it is the only thing that determines the kind of
> processing, but it won't stay like that.

I may be not up to date with maven-new internal, but I imaging this like
that: A plugin is invoked (because a goal defined by in was requested),
then it picks up a predefined set of dependencies and processes each
one in turn. The exact actions taken for the dependency may depend
on the dependency type of course (a tld is processed differently
than a jar by the war plugin for example).

>>Kind (class, nature?) determines in which of the productions you've
>>mentioned the artifact show up. 
> 
> 
> Artifact or anything else that is derived from a dependency.

I meant what set/collection the dependency shows up. I think that in
most contexts it makes little sense to extract information from each
dependency in turn and pile it up together. If you look at properties
declared per-dependency, consolidating them makes not sense.

>>because it's supposed to be specific
>>for the war plugin. I'd much rather have:
>>
>><dependency-set>war</dependency-set>
> 
> 
> You mean defining a set of properties that are valid for use with the
> WAR plugin? Yup, that will be necessary for other things as well.

No I didn't mean that. I meant that war plugin could declare a
depencency set specific to itself in paralell to sets "build" "runtime"
and "test" declared by the core. Later on I noticed that the war
plugin should be using the "runtime" set really.

>>Or along the lines of David's comment
>>
>><dependency class="war">
>></dependency>
> 
> What if you have more than one class? Sorry, don't understand this one.

It was suposed to mimic css class notation. When there is more than one
you put them all into the attribute, whitespace separated.


>>Or even better along the lines of Michals latest propsal, one of the 
>>aboved with "war" replaceed by "runtime", and the war plugin knowing
>>that it should pick up all artifacts from "runtime" set/production
>>and bundle them together.
> 
> 
> You wouldn't even have to specify this as the WAR plugin could pick up
> the standard runtime jar list production. I see that one as a standard
> one. You could do that in conjunction with an exclude option on the
> depedency. Just so long as the user can control exactly what goes into
> the WAR and what doesn't. Inclusion of a standard production with
> exclusions would probably make more sense with the WAR plugin I think.

I agree.

R.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: POM and maven-new

[Jason van Zyl <ja...@zenplex.com>]

On Sat, 2003-06-07 at 17:53, Rafal Krzewski wrote:
> Jason van Zyl wrote:
> 
> > I believe that <type> and <kind> can be replaced with a single set of
> > hints. And here the hints are specifically artifact handler hints.
> 
> Maybe I just understand, but for me <type> (jar,war,tld...) and <kind>
> (compile,runtime,test,...) are orthogonal qualities of a dependency.

We'll probably find there are more orthogonal sets of qualities as you
put it. Whatever is more clear I'm fine with. To me the type is just
another piece of information.

> Type determines the filename, and repository location of the artifact,
> but does not affect the kind of processing the artifact will recieve.

Currently in maven-new it is the only thing that determines the kind of
processing, but it won't stay like that.

> Kind (class, nature?) determines in which of the productions you've
> mentioned the artifact show up. 

Artifact or anything else that is derived from a dependency.

> I don't think that we should mix
> those two qualities together, because IMO this will effectively
> *decrease* consistency.

The notation isn't cast in stone.

> > Say we have the following POM:
> > 
> > <pom>
> >   <dependencies>
> >     <dependency>
> >       <groupId></groupId>
> >       <artifactId></artifactId>
> >       <hints>
> >         <type>jar</type>
> >         <war>true</war>
> >       </hints>
> >     </dependency>
> >     <dependency>
> >       <groupId></groupId>
> >       <artifactId></artifactId>
> >       <hints>
> >         <type>jar</type>
> >         <war>true</war>
> >       </hints>
> >     </dependency>
> >     <dependency>
> >       <groupId></groupId>
> >       <artifactId></artifactId>
> >       <hints>
> >         <type>jar</type>
> >         <test>true</test>
> >       </hints>
> >     </dependency>
> >   </dependencies>
> > </pom>
> > 
> > So instead of an artifact being passed through only one artifact handler
> > it passes through a chain of artifact handlers and each artifact handler
> > does what it likes with the artifact based on hinting information.
> > 
> > So we may have some standard artifact handlers in the core, but I see
> > many of the artifact handlers coming from plugins themselves. When a
> > plugin is loaded the artifact handlers it provides are loaded into the
> > artifact handler chain. When it's finished they can be removed. So for
> > example with the WAR plugin it would have a simple artifact handler that
> > looked for 'war=true' hint and if found would add that artifact to a
> > production which was a list of artifacts you wanted packed into a WAR.
> 
> All of this is fine, perhaps except the notation. I'd hate to have <war>
> element declared in the POM schema, 

True enough. I wouldn't want that either.

> because it's supposed to be specific
> for the war plugin. I'd much rather have:
> 
> <dependency-set>war</dependency-set>

You mean defining a set of properties that are valid for use with the
WAR plugin? Yup, that will be necessary for other things as well.

> Or along the lines of David's comment
> 
> <dependency class="war">
> </dependency>

What if you have more than one class? Sorry, don't understand this one.

> Or even better along the lines of Michals latest propsal, one of the 
> aboved with "war" replaceed by "runtime", and the war plugin knowing
> that it should pick up all artifacts from "runtime" set/production
> and bundle them together.

You wouldn't even have to specify this as the WAR plugin could pick up
the standard runtime jar list production. I see that one as a standard
one. You could do that in conjunction with an exclude option on the
depedency. Just so long as the user can control exactly what goes into
the WAR and what doesn't. Inclusion of a standard production with
exclusions would probably make more sense with the WAR plugin I think.

> > So I see the POM being able to store an arbitrary map of productions and
> > it would be up to the artifact handler to name the production. So when
> > the artifacts are processed any number of productions can be created and
> > stored in the POM. When a plugin is executed it has access to the POM
> > and can extract the productions it needs to carry out its task.
> > 
> > So this way everything is offloaded to the plugin. If the standard
> > productions don't suit the plugin then the plugin provides 1..n artifact
> > handlers to create the productions it needs. And the artifact handler is
> > simply triggered by the hinting information.
> > 
> > The <hints> could also be <properties>, I don't really care. I'm just
> > trying to stress that a single set of hints or properties would do the
> > trick as all we are really trying to do is provide some arbitrary set of
> > information to a plugin and I believe this will work.
> 
> At this moment I don't see any particular use for free-form key=value 
> style properties attached to a dependency, but at the same time I cannot
> deny that some artifact handler might need that. My preferable syntax 
> for those would be

Who knows what you might want to parameterize. I figure a property style
notation can't hurt. 

> <dependency>
>    <properties>
>      <property name="name">value</property>
>    </properties>
> </dependency>
> 
> or in case we can't have XML attributes
> 
> <dependency>
>    <properties>
>      <property>
>        <name>name</name>
>        <value>value</value>
>      </property>
>    </property>
> </dependency>

I'm sure we'll figure out the notation.

> > We could also use the hinting information to access the artifact type
> > directory or anything else that would be required in the artifact
> > processing chain.
> 
> See at the top of the message.
> 
> > I will actually send another message about transitive dependencies to
> > keep the ideas separated.
> 
> Looking forward to it.
> 
> R.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
-- 
jvz.

Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: POM and maven-new

[Rafal Krzewski <Ra...@caltha.pl>]

Jason van Zyl wrote:

> I believe that <type> and <kind> can be replaced with a single set of
> hints. And here the hints are specifically artifact handler hints.

Maybe I just understand, but for me <type> (jar,war,tld...) and <kind>
(compile,runtime,test,...) are orthogonal qualities of a dependency.
Type determines the filename, and repository location of the artifact,
but does not affect the kind of processing the artifact will recieve.
Kind (class, nature?) determines in which of the productions you've
mentioned the artifact show up. I don't think that we should mix
those two qualities together, because IMO this will effectively
*decrease* consistency.

> Say we have the following POM:
> 
> <pom>
>   <dependencies>
>     <dependency>
>       <groupId></groupId>
>       <artifactId></artifactId>
>       <hints>
>         <type>jar</type>
>         <war>true</war>
>       </hints>
>     </dependency>
>     <dependency>
>       <groupId></groupId>
>       <artifactId></artifactId>
>       <hints>
>         <type>jar</type>
>         <war>true</war>
>       </hints>
>     </dependency>
>     <dependency>
>       <groupId></groupId>
>       <artifactId></artifactId>
>       <hints>
>         <type>jar</type>
>         <test>true</test>
>       </hints>
>     </dependency>
>   </dependencies>
> </pom>
> 
> So instead of an artifact being passed through only one artifact handler
> it passes through a chain of artifact handlers and each artifact handler
> does what it likes with the artifact based on hinting information.
> 
> So we may have some standard artifact handlers in the core, but I see
> many of the artifact handlers coming from plugins themselves. When a
> plugin is loaded the artifact handlers it provides are loaded into the
> artifact handler chain. When it's finished they can be removed. So for
> example with the WAR plugin it would have a simple artifact handler that
> looked for 'war=true' hint and if found would add that artifact to a
> production which was a list of artifacts you wanted packed into a WAR.

All of this is fine, perhaps except the notation. I'd hate to have <war>
element declared in the POM schema, because it's supposed to be specific
for the war plugin. I'd much rather have:

<dependency-set>war</dependency-set>

Or along the lines of David's comment

<dependency class="war">
</dependency>

Or even better along the lines of Michals latest propsal, one of the 
aboved with "war" replaceed by "runtime", and the war plugin knowing
that it should pick up all artifacts from "runtime" set/production
and bundle them together.

> So I see the POM being able to store an arbitrary map of productions and
> it would be up to the artifact handler to name the production. So when
> the artifacts are processed any number of productions can be created and
> stored in the POM. When a plugin is executed it has access to the POM
> and can extract the productions it needs to carry out its task.
> 
> So this way everything is offloaded to the plugin. If the standard
> productions don't suit the plugin then the plugin provides 1..n artifact
> handlers to create the productions it needs. And the artifact handler is
> simply triggered by the hinting information.
> 
> The <hints> could also be <properties>, I don't really care. I'm just
> trying to stress that a single set of hints or properties would do the
> trick as all we are really trying to do is provide some arbitrary set of
> information to a plugin and I believe this will work.

At this moment I don't see any particular use for free-form key=value 
style properties attached to a dependency, but at the same time I cannot
deny that some artifact handler might need that. My preferable syntax 
for those would be

<dependency>
   <properties>
     <property name="name">value</property>
   </properties>
</dependency>

or in case we can't have XML attributes

<dependency>
   <properties>
     <property>
       <name>name</name>
       <value>value</value>
     </property>
   </property>
</dependency>

> We could also use the hinting information to access the artifact type
> directory or anything else that would be required in the artifact
> processing chain.

See at the top of the message.

> I will actually send another message about transitive dependencies to
> keep the ideas separated.

Looking forward to it.

R.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org