If I can add my 2 cents to this discussion
I fail to see other then performance related issues why 'runtime'
dependencies should not be visible for
all plugins (e.g. for compile process of java plugin). Simple is good.
So how it is now it's in my opinion not bad.
BTH: I believe that what was called run time dependency in this discussion
should be rather call "deployable dependency".
Including/Excluding of deployable dependecy should be handled by plugins
which are generating
deployable artifacts (war, ear etc). So simply as it is currently:
(e.g. for WAR plugin)
<properties>
<war.bundle.jar>true</war.bundle.jar>
</properties>
What should be consider here, once arbitrary artifact type handling
is ready, is how to support other types of arifact in such process.
For example Struts distribution is consisting of jar, tld files
Do we need to have:
<properties>
<war.bundle.jar>true</war.bundle.jar>
</properties>
<properties>
<war.bundle.tld>true</war.bundle.tld>
</properties>
<properties>
<war.bundle.js>true</war.bundle.js>
</properties>
etc?
Maybe the plugin should be smart enough to know what to do with artifacts of
different type?
e.g:
<dependency>
<groupId>myJar</groupId>
<artifactId>myJar</artifactId>
<version>x.x</version>
<properties>
<war.bundle>true</war.bundle>
</properties>
<type>jar</type>
</dependency>
<dependency>
<groupId>myJar</groupId>
<artifactId>myTLD</artifactId>
<version>y.y</version>
<properties>
<war.bundle>true</war.bundle>
</properties>
<type>tld</type>
</dependency>
will result in following packaging:
myWar
-WEB-IF
- lib
- myJar-x.x.jar
- tlds
- myTLD-y.y.tld
Michal
> -----Original Message-----
> From: Ben Walding [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 24, 2003 2:51 AM
> To: Maven Users List
> Subject: Re: again: Runtime dependency VS compile time dependecy
>
>
> As far as I can tell you essentially want to categorize
> dependencies. Or am I thinking of something completely different?
>
> So some options:
>
> <dependency>
> <id>jarid</id>
> <version>jarversion</version>
> <compiletimedependency/>
> <runtimedependency/>
> </dependency>
>
> Advantages: xsd locks down values
> Disadvantages: hardwired, requires xsd changes for each new
> dependency group
>
> vs.
>
> <dependency>
> <id>jarid</id>
> <version>jarversion</version>
> <dependencyGroup>compile</dependencyGroup>
> <dependencyGroup>runtime</dependencyGroup>
> </dependency>
>
> Advantages: can have arbitrary groups without changing xsd (if
> xsd does not mandate contents of dependencyGroup)
> Disadvantages: "magic" values - runtime, compile, war, ear, jar,
> jnlp etc (which xsd can mandate - catch 22)
>
>
> vs
>
> <dependency>
> <id>jarid</id>
> <version>jarversion</version>
>
> <property><name>dependency.group.compile</name><value>true</value>
> </property>
> <property><name>runtime</name><value>true</value></property>
> </dependency>
>
> Advantages: Currently in use by war target and others (eg. jnlp)
> Disadvantages: Having dependency groups probably warrants new xsd
> elements. Jelly script would be cleaner with previous options.
> Also relies even more heavily on magic values.
>
>
>
>
>
>
> Paulo Silveira wrote:
>
> >So Ben Walding and comitters, why not take this approach? I am not
> >talking only about the dependency case, but all cases that generates
> >specifif tags in the POM that is only used for a specific plugin.
> >
> >I know Jason is working in sth that can help us in the dependency
> >problem... Can you share?
> >
> >------------------------
> >Paulo Silveira
> >http://www.paulo.com.br/
> >http://www.guj.com.br/
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Ben Walding [mailto:[EMAIL PROTECTED]
> >>Sent: domingo, 23 de mar�o de 2003 17:30
> >>To: Maven Users List
> >>Subject: Re: again: Runtime dependency VS compile time dependecy
> >>
> >>
> >>Sure is... consider servlet-api
> >>
> >>I need it to compile, but my j2ee container provides it at runtime.
> >>
> >>Henri Yandell wrote:
> >>
> >>
> >>
> >>>Is there any time when a dependency is compile-time but not
> >>>
> >>>
> >>runtime? It
> >>
> >>
> >>>seems to me that all dependencies are needed at runtime.
> >>>
> >>>On Sun, 23 Mar 2003, Paulo Silveira wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>I think it is not good to have so specific plugin tags
> >>>>
> >>>>
> >>inside the POM,
> >>
> >>
> >>>>dont you think?
> >>>>
> >>>>The good example is <war.bundle.jar>true</war.bundle.jar>
> >>>>Why we couldnt have a tag that specifies if a dependecy is only
> >>>>runtime, compiletime, or both? Maybe 2 tags
> >>>>
> >>>><dependency>
> >>>> <id>jarid</id>
> >>>> <version>jarversion</version>
> >>>> <compiletimedependency/>
> >>>> <runtimedependency/>
> >>>></dependency>
> >>>>
> >>>>thanks
> >>>>
> >>>>------------------------
> >>>>Paulo Silveira
> >>>>http://www.paulo.com.br/
> >>>>http://www.guj.com.br/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>------------------------------------------------------------
> >>>>
> >>>>
> >>---------
> >>
> >>
> >>>>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]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>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]
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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]
