On Thu, 2003-06-26 at 10:44, Michal Maczka wrote:
> I think that looping over project properties is quite dangerous.
> If you use project inheritance, sometimes you might be interested
> in overriding some properties of parent project.
>
> In this case you cannot switch off any repository defined
dion2003/06/26 23:54:47
Added: src/plugins-build/reactor .cvsignore plugin.jelly
plugin.properties project.properties project.xml
src/plugins-build/reactor/xdocs .cvsignore changes.xml
goals.xml index.xml navigation.xml
dion2003/06/26 23:53:38
maven/src/plugins-build/reactor/xdocs - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
dion2003/06/26 23:53:16
maven/src/plugins-build/reactor - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
If we don't have to rejig the properties for all the plugins, I'm +1 on
the new dotted syntax.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Jason van Zyl <[EMAIL PROTECTED]> wrote on 26/06/2003 10:31:01 PM:
> On T
I think I've asked this before, but AFAIK,
distributionSite and distributionDirectory are not related AT ALL to
maven.repo.central.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Michal Maczka <[EMAIL PROTECTED]> w
Brian Ewins <[EMAIL PROTECTED]> wrote on 26/06/2003
06:29:09 PM:
> Michal Maczka wrote:
>
> >
> > I think we should go step further and get rid of plugin.properties
file...
> > in favour of metadata file.
> > It can look like:
> [snip]
> > BTW: We anyway need plugin metadata file which can be
Message:
The following issue has been closed.
Resolver: Jason van Zyl
Date: Thu, 26 Jun 2003 9:30 PM
This is now in effect with a patch by Aslak.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?k
Message:
The following issue has been closed.
Resolver: Jason van Zyl
Date: Thu, 26 Jun 2003 9:21 PM
Doco updated.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-287
Here is an overv
jvanzyl 2003/06/26 19:01:14
Modified:xdocs/reference user-guide.xml
Log:
o ditto
Revision ChangesPath
1.53 +0 -2 maven/xdocs/reference/user-guide.xml
Index: user-guide.xml
===
RCS file: /ho
jvanzyl 2003/06/26 19:00:58
Modified:xdocs/reference dirlayout.xml
Log:
o Simply remove references to driver.properties because it will disappear
shortly and we don't want users knowing about it or trying to tinker
with it.
Revision ChangesPath
1.7 +1 -2
Message:
The following issue has been closed.
Resolver: Jason van Zyl
Date: Thu, 26 Jun 2003 9:15 PM
The only place where the value is hardcoded is for the bootstrap and that's a
reasonable expectation.
-
View the
On Thu, 2003-06-26 at 17:46, Brett Porter wrote:
> I thought Vincent was saying that he thought plugin="xdoc" name="maven.dest.dir" value="dest.dir"/> was better to
> avoid namespace confusion?
There will no longer be any namespace confusion as what's in a plugin is
completely separate. You coul
I thought Vincent was saying that he thought was better to
avoid namespace confusion?
In that case I agree, because I'm not sure how Velocity is going to tell
between plugins, antlr and "src.dir", without thinking it needs to do
getSrc().getDir(), but it might work. IT also rules out having ".
On Thu, 2003-06-26 at 14:44, bob mcwhirter wrote:
> > As far as property accessing within a plugin:
> >
> > ${maven.compile.target}
>
> So, just like normal, right?
I was actually thinking of just making property access the same across
the board so everywhere it's just
${plugins..}
So for exa
> As far as property accessing within a plugin:
>
> ${maven.compile.target}
So, just like normal, right?
> to access properties defined by the plugin itself and
>
> ${plugins.antlr.src.dir}
>
> to access properties defined in other plugins, this example showing
> access to the antlr plugin's
kaz 2003/06/26 11:36:40
Modified:src/plugins-build/uberjar plugin.jelly
Log:
Patch from Chris Shorrock <[EMAIL PROTECTED]>. Thanks!
Revision ChangesPath
1.5 +1 -1 maven/src/plugins-build/uberjar/plugin.jelly
Index: plugin.jelly
=
On Thu, 2003-06-26 at 12:51, Jason van Zyl wrote:
> On Thu, 2003-06-26 at 10:41, Jason van Zyl wrote:
>
>
> > ${plugins.antlr.src.dir}
> >
> > to access properties defined in other plugins, this example showing
> > access to the antlr plugin's properties.
>
> The only problem with this is that
On Thu, 2003-06-26 at 10:41, Jason van Zyl wrote:
> ${plugins.antlr.src.dir}
>
> to access properties defined in other plugins, this example showing
> access to the antlr plugin's properties.
The only problem with this is that jexl(velocity) doesn't deal with this
very well as I soon found out.
Hi,
I just wanted to summarize some of the past few emails regarding
properties use in plugins and the files used to define plugins.
As far as the files used to define plugins I think the best idea came
from Mark H. Wilkinson where the standard file names are used but they
are just placed in a di
On Thu, 2003-06-26 at 08:23, Michal Maczka wrote:
> I like this idea!
I agree, that is a good idea. It definitely allows using the same tools
throughout the source code. Having the little niggly bits for reading
plugin.jelly and plugin.properties causes some problems internally.
I think this is t
On Thu, 2003-06-26 at 01:40, [EMAIL PROTECTED] wrote:
> How would we be able to differentiate then between the properties a plugin
> exposes and those it uses for it's own purposes? The plugin plugin uses
> plugin.properties to generate docs.
Ok, it looks like we will keep both in order to make
On Thu, 2003-06-26 at 01:34, Vincent Massol wrote:
> I like the second form personally although I agree it is less
> understandable than the first. Thus, I would think the first is probably
> the best to avoid namespace confusion.
Ok, so you are in favour of the ${foo} form for both. Cool, I'll
On Thu, 2003-06-26 at 01:27, Vincent Massol wrote:
> ATM I have different properties in plugin.properties and in
> project.properties. The ones in project.properties are used to build the
> plugin only and they must not be used when the user uses the plugin.
>
> How do we deal with this?
Again I
I like this idea!
mm
> -Original Message-
> From: Mark H. Wilkinson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 26, 2003 11:10 AM
> To: Maven Developers List
> Subject: Re: Aligning plugin artifacts with normal projects
>
> On Wed, 2003-06-25 at 22:58, Jason van Zyl wrote:
> > Hi,
>
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-520
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-519
Here is an overview of the issue:
--
On Wed, 2003-06-25 at 22:58, Jason van Zyl wrote:
> Hi,
>
> We had a quick chat in IRC about aligning plugin artifacts with normal
> Maven Projects. By this I mean using maven.xml instead of plugin.jelly
> and the simple project.properties instead of plugin.properties.
Responses seem to be sugges
> -Original Message-
> From: Martin Skopp [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 26, 2003 8:40 AM
> To: Maven Developers List
> Subject: Re: Deploy API (artifact plugin)
>
> On Wed, 2003-06-25 at 15:20, Michal Maczka wrote:
> > I have progressed with Deployer API.
>
> Wow, tha
Stealing my ideas and passing them off as your own eh :P
http://wiki.codehaus.org/general/Maven_2fPluginMetadata
Michal Maczka wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 7:41 AM
To: Maven Developers List
Subject: Re: Align
Michal Maczka wrote:
I think we should go step further and get rid of plugin.properties file...
in favour of metadata file.
It can look like:
[snip]
BTW: We anyway need plugin metadata file which can be used by IDEs.
Agree 100%.
We also need it for documentation. Its quite common for people to a
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 26, 2003 7:41 AM
> To: Maven Developers List
> Subject: Re: Aligning plugin artifacts with normal projects
>
> How would we be able to differentiate then between the properties a plugin
> expo
Last 500 lines of a clean bootstrap build of maven at 20030626-0317
U maven/src/plugins-build/xdoc/src/plugin-resources/images/icon_alert.gif
U maven/src/plugins-build/xdoc/src/plugin-resources/images/nw_min.gif
U maven/src/plugins-build/xdoc/src/plugin-resources/images/remove.gif
U maven/src
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: 26 June 2003 09:16
> To: Maven Developers List
> Subject: Re: multiple source directories... my turn... :-)
>
> >>Is that OK? You probably also need some postGoal for copying the
> >>deployed JAR.
> >
> >
> > Not
I could only find it on the Jelly site :)
- Brett
Ben Walding wrote:
irc.codehaus.org:6667
#maven
Probably is documented, but I have no idea where :)
Martin Skopp wrote:
--
Web Developer
f2 network ~ everything essential
02 8596 4437
---
Is that OK? You probably also need some postGoal for copying the
deployed JAR.
Not sure why.
I thought maybe you wanted to build a JAR with a different name -
otherwise it will always be ${pom.artifactId}-${pom.version}.jar, which
will only have 1 value. I probably misunderstood.
Cheers,
Bret
irc.codehaus.org:6667
#maven
Probably is documented, but I have no idea where :)
Martin Skopp wrote:
On Wed, 2003-06-25 at 23:58, Jason van Zyl wrote:
We had a quick chat in IRC about aligning plugin artifacts with normal
Is there a special maven channel where you guy hang around?
Could
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: 26 June 2003 09:04
> To: Maven Developers List
> Subject: Re: multiple source directories... my turn... :-)
>
> I think you are looking for:
>
>
>
location="${pom.build.sourceDirectory}/../${j2ee.versio
I think you are looking for:
Where your sourceDirectory is src/java/share, and j2ee.version=j2ee12
for example.
Is that OK? You probably also need some postGoal for copying the
deployed JAR.
I'm not sure how it works out with tests though - you could check that
it is using a
39 matches
Mail list logo
