RE: Deploy API (artifact plugin)
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 in parent project, Ok, so it's a feature, not a bug :-) If no repo.list is found, you could loop over all repos as a default behaviour. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/reactor/xdocs .cvsignore changes.xml goals.xml index.xml navigation.xml properties.xml
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 properties.xml
Log:
add reactor plugin
Revision ChangesPath
1.1 maven/src/plugins-build/reactor/.cvsignore
Index: .cvsignore
===
target
*.log
1.1 maven/src/plugins-build/reactor/plugin.jelly
Index: plugin.jelly
===
A goal to run must be specified, e.g.
maven -Dgoal=clean reactor:goal
Executing ${goal} on all reactored projects
1.1 maven/src/plugins-build/reactor/plugin.properties
Index: plugin.properties
===
# ---
# P L U G I N P R O P E R I E S
# ---
# Reactor plugin.
# ---
maven.reactor.basedir=${basedir}
maven.reactor.includes=*/project.xml
maven.reactor.excludes=
maven.reactor.ignoreFailures=false
1.1 maven/src/plugins-build/reactor/project.properties
Index: project.properties
===
# ---
# P R O J E C T P R O P E R T I E S
# ---
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
maven.license.licenseFile=${basedir}/../../../LICENSE.txt
1.1 maven/src/plugins-build/reactor/project.xml
Index: project.xml
===
${basedir}/../project.xml
maven-reactor-plugin
Maven Reactor Plug-in
1.0-SNAPSHOT
A plugin to handle the building of subprojects within
maven
Reactor Plugin for Maven
http://maven.apache.org/reference/plugins/reactor/
/www/maven.apache.org/reference/plugins/reactor/
scm:cvs:pserver:[EMAIL
PROTECTED]:/home/cvspublic:maven/src/plugins-build/reactor/
http://cvs.apache.org/viewcvs/maven/src/plugins-build/reactor/
dIon Gillard
dion
[EMAIL PROTECTED]
Multitask Consulting
Java Developer
1.1 maven/src/plugins-build/reactor/xdocs/.cvsignore
Index: .cvsignore
===
stylesheets
1.1 maven/src/plugins-build/reactor/xdocs/changes.xml
Index: changes.xml
===
Changes
dIon Gillard
Initial creation during 1.0-beta 10 dev phase
1.1 maven/src/plugins-build/reactor/xdocs/goals.xml
Index: goals.xml
===
Maven Reactor Plug-in Goals
dIon Gillard
reactor
Run the site goal of all subprojects
reactor:site
Run the site goal of all subprojects
reactor:goal
Run the comma separated list of goal provided by the variable
goal for all subprojects
e.g.
maven -Dgoal=java:compile reactor:goal
or
maven -Dgoal=clean,java:compile,test reactor:goal
1.1 maven/src/plugins-build/reactor/xdocs/index.xml
Index: index.xml
===
Maven Eclipse Plugin
dIon Gillard
This plug-in provides the ability to work with subprojects via the same
interface
as a single project
For more information on the functionality provided by this plugin,
please see the Goals document.
For more information on how to customise the functionality provided
by this plugin, please see the properties
document.
1.1 maven/src/plugins-bui
cvs commit: maven/src/plugins-build/reactor/xdocs - New directory
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]
cvs commit: maven/src/plugins-build/reactor - New directory
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]
RE: Standard method for retrieving plugin properties in plugins
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 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 keep
> track. After thinking about it I think I like that too.
>
> ${maven.compile.target}
>
> ${plugins.antlr.src.dir}
>
> If I can get this to work this is what you would prefer, yes?
>
> > -Vincent
> >
> > >
> > > --
> > > jvz.
> > >
> > > Jason van Zyl
> > > [EMAIL PROTECTED]
> > > 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> --
> jvz.
>
> Jason van Zyl
> [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
RE: Deploy API (artifact plugin)
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]> wrote on 26/06/2003 06:44:19 PM: > > > > -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, that *really* looks good... > > > > > #list of repositories to which we will deploy > > > maven.repo.repos= R1, R2, R3, R4, ibiblio > > > > Is there really need for this property? > > I am just afraid of users forgetting to add to this property which will > > raise question on the mailinglist > > > > Possible reaons from my point of view: > > > > a) convenience for Michal :-) > > He does not need to loop over all properties check for a maven.repo.* > > match... > > > > 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 in parent project, > > And you should not be aware of them. > > But you are 100% right that it should be simpler. > That's why I asked for comments, hoping that somebody will have > an idea how to simplify. > > BTW: It's even more complicated then I have described last time. > > Silently I assume existence of default (central repository). > Some setting of this repository are matching > > > > > Tags in POM > > This repository is silently named "central". > > It's clear that in POM there is no place for some properties of this > repository (like username, password, passpharse of private key, proxy host > etc). > > Other settings used this repository are currently described in > (BTW: why they are there? It's very hard to find them!) > > http://maven.apache.org/reference/plugins/jar/properties.html > > Namely: > > maven.repo.central > maven.repo.central.directory > maven.username > maven.remote.group > > > I will try to hack my code to make it backward compatible ... but among > those settings you won't find e.g. user's password. I need to know it. > :( > > > > For the moment using my (poor!!) naming convention you can use: > > #(don't have to use it if tag was used in POM > maven.repo.central=www.apache.org > > #(don't have to use it if tag was used) > maven.repo.central.directory= > > > maven.repo.central.username > maven.repo.central.group > maven.repo.central.password > maven.repo.central.passphrase > maven.repo.central.privatekey > maven.repo.central.port > maven.repo.central.proxy.host > maven.repo.central.proxy.port > maven.repo.central.proxy.username > maven.repo.central.proxy.password > > I think that it is more consistent...but way too complicated. > > Michal > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: Aligning plugin artifacts with normal projects
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 used by IDEs. > > Agree 100%. > > We also need it for documentation. Its quite common for people to ask > 'what property do I set to do' because there are so many > undocumented properties. If there was a metadata file that described > plugin properties, it could be used to generate the xdocs. There is one. It's called plugin.properties, and it can be used to generate the xdocs :-) The reason the documentation is lacking is noone has been willing to do it. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Work: http://www.multitask.com.au
[jira] Closed: (MAVEN-149) Work dir for Maven
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?key=MAVEN-149 Here is an overview of the issue: - Key: MAVEN-149 Summary: Work dir for Maven Type: Improvement Status: Closed Priority: Minor Resolution: FIXED Time Spent: Unknown Estimate: 0 minutes Project: maven Components: core Versions: 1.0-beta-8 Assignee: Jason van Zyl Reporter: Vincent Massol Created: Tue, 5 Nov 2002 9:12 AM Updated: Thu, 26 Jun 2003 9:30 PM Description: It would be nice for Maven to have a work directory. For example, ATM, the plugins get expanded in mavenhome/plugins, along the plugin jar files. It isn't very clean. I believe a better solution would be to have a maven work directory that could be different from where Maven is installed. This could default to the windows temporary directory on windows machines for example. (note: I'm putting maven in CVS and then everyone on our projects gets it automatically installed by doing CVS update. When I do a CVS update I get lots of "?" because the expanded plugins are not in CVS... In additio there is always the risk that someone will add them to CVS). Thanks -Vincent - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVEN-287) driver.properties location
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 overview of the issue: - Key: MAVEN-287 Summary: driver.properties location Type: Bug Status: Closed Priority: Major Resolution: FIXED Time Spent: Unknown Estimate: 0 minutes Project: maven Versions: 1.0-beta-8 Assignee: Jason van Zyl Reporter: Vasiliy Gagin Created: Thu, 20 Feb 2003 12:52 PM Updated: Thu, 26 Jun 2003 9:21 PM Environment: Windows 2000 Description: According to documentation and common sence file driver.properties should be located in $MAVEN_HOME/bin directory. But class org.apache.maven.MavenUtils is using ClassLoader.getResourceAsStream() method and thus reads file from maven.jar. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/xdocs/reference user-guide.xml
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: /home/cvs/maven/xdocs/reference/user-guide.xml,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- user-guide.xml22 Apr 2003 11:48:50 - 1.52
+++ user-guide.xml27 Jun 2003 02:01:14 - 1.53
@@ -519,7 +519,6 @@
-${maven.home}/bin/driver.properties
${project.home}/project.properties
${project.home}/build.properties
${user.home}/build.properties
@@ -556,7 +555,6 @@
Plug-in default properties are processed
-${maven.home}/bin/driver.properties are processed
${project.home}/project.properties are processed
${project.home}/build.properties are processed
${user.home}/build.properties are processed
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/xdocs/reference dirlayout.xml
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 maven/xdocs/reference/dirlayout.xml
Index: dirlayout.xml
===
RCS file: /home/cvs/maven/xdocs/reference/dirlayout.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- dirlayout.xml 12 Jun 2003 08:40:52 - 1.6
+++ dirlayout.xml 27 Jun 2003 02:00:58 - 1.7
@@ -143,8 +143,7 @@
This file can be used to override Maven default properties
- for the core and various plugins (defined in
${maven.home}/src/conf/driver.properties and
- /plugin.properties in each respective plugin).
+ for the core and properties for the various plugins.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVEN-511) www.ibiblio.org is hard coded in too many places
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 issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-511
Here is an overview of the issue:
-
Key: MAVEN-511
Summary: www.ibiblio.org is hard coded in too many places
Type: Bug
Status: Closed
Priority: Major
Resolution: WON'T FIX
Time Spent: Unknown
Estimate: 0 minutes
Project: maven
Components:
core
Versions:
1.0-beta-10
Assignee: Jason van Zyl
Reporter: dion gillard
Created: Sun, 22 Jun 2003 10:35 PM
Updated: Thu, 26 Jun 2003 9:15 PM
Description:
Hi,
We have a problem with the (stupidly high level of) security of our
internet proxy which makes it practically impossible for us to reliably get
to www.ibiblio org. Therefore we have an internal mirror of ibiblio via
Jobo : http://www.matuschek.net/software/jobo/
What I want to do is to do an itnernal build of maven pointing to our
internal mirror.
However, I notice that there are a number of places where www.ibiblio.org
is "hard-coded" in.
I suspect that some of these are entirely necessary - I'd appreciate it if
anyone can back me up.
The rest I will mod and submit a patch.
Here they are:
---
/build-bootstrap.properties:
line 1: maven.get.jars.baseUrl = http://www.ibiblio.org/maven
I suspect that this case is unavoidable.
However, could we read in the default.properties as well?
---
/src/plugins-build/examples/exampleear-1.0/build.xml
line 135: http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.2.jar
">
line 137: http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
">
Should this be changed to:
?
---
/src/plugins-build/jar/plugin.jelly:
line 79: http://www.ibiblio.org/maven${artifact.urlPath}"/>
Should this be changed to:
?
---
/src/plugins-build/plexus/plugin.jelly:
line 163: src="http://www.ibiblio.org/maven/plexus/jars/
${plexusPom.artifactId}-${plexusPom.currentVersion}.jar"
line 282: src="http://www.ibiblio.org/maven/plexus/jars/
${depPom.artifactId}-${depPom.currentVersion}.jar"
line 338: src="
http://www.ibiblio.org/maven/plexus/plexus-component.manifest";
line 370: src="http://www.ibiblio.org/maven/plexus/poms/${component}.pom";
FOR i 1 TO 5 DO SUBS(http://www.ibiblio.org/maven, ${maven.repo.remote})
?
---
/src/plugins-build/release/src/main/org/apache/maven/release/SnapshotResolver.java
/*
String url = getVariables().get( MavenConstants.REPO_REMOTE ) + "/" +
groupId + "/jars/" + artifactId + "-snapshot-version";
*/
line 124: String url = "http://www.ibiblio.org/maven/"; + groupId + "/jars/"
+ artifactId + "-snapshot-version";
Should the commented-out code be uncommented back in?
---
Thanks,
Cheese,
-Nick
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standard method for retrieving plugin properties in plugins
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 could have the same property in many plugins
now and the value for the particular plugin will stay attached to the
plugin it belongs too. There are now separate classloaders for the
plugins as well.
> 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()
It can't which is why I am in favour of using standard Java naming
conventions for properties. This also makes sense name space wise if you
compare:
${plugins.antlr.srcDir}
as opposed to
${plugins.antlr.src.dir}
This is what I've started working toward.
> , but it might work. IT also rules out having "." in a
> plugin name - not a big deal, but worth checking.
We will need a standard naming convention for plugins too. Definitely no
"."s allowed and I haven't tried yet but I'm pretty sure I'm going to
run into a problem with the few plugins that have hyphens because jexl
is going to try and substract.
> As an aside, how do you assign to the variable, or is that not allowed
> outside of the plugin?
In the cases where this needs to be done you could grab hold of the Map
which contains the plugins properties. So, for example, if you wanted to
change the srcDir in the antlr plugin you would use:
${plugins.antlr.put( "srcDir", "/path" )}
I agree this is not the most element solution but a tag could be made
too if desired. But in most cases where you just want to read the
property
${plugins.antlr.srcDir}
is clear I believe.
> Cheers,
> Brett
>
> Jason van Zyl wrote:
> > 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 keep
> > track. After thinking about it I think I like that too.
> >
> > ${maven.compile.target}
> >
> > ${plugins.antlr.src.dir}
> >
> > If I can get this to work this is what you would prefer, yes?
> >
> >
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standard method for retrieving plugin properties in plugins
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 "." in a
plugin name - not a big deal, but worth checking.
As an aside, how do you assign to the variable, or is that not allowed
outside of the plugin?
Cheers,
Brett
Jason van Zyl wrote:
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 keep
track. After thinking about it I think I like that too.
${maven.compile.target}
${plugins.antlr.src.dir}
If I can get this to work this is what you would prefer, yes?
--
Web Developer
f2 network ~ everything essential
02 8596 4437
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Summary
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 example
${plugins.antlr.srcDir}
The alteration being that jexl/velocity won't work when it's like
${plugins.antlr.src.dir}
So there would be one style of access across the board.
> > 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 properties.
>
> Sounds like a plan to me.
>
> +1.
>
> -bob
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Summary
> 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 properties.
Sounds like a plan to me.
+1.
-bob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/uberjar plugin.jelly
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 === RCS file: /home/cvs/maven/src/plugins-build/uberjar/plugin.jelly,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- plugin.jelly 22 Apr 2003 11:48:50 - 1.4 +++ plugin.jelly 26 Jun 2003 18:36:40 - 1.5 @@ -16,7 +16,7 @@ - + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Summary
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 jexl(velocity) doesn't deal with this
> very well as I soon found out. So something like:
>
> ${plugins.java.maven.compile.target}
>
> doesn't resolve but
>
> ${plugins.java.mavenCompileTarget}
>
> does.
>
> So we can either standardize on property names to follow the same
> convention as Java variables or come up with a different way to access
> properties from external plugins.
The properties as java variable names works just fine and as a final
option we could just use:
${plugin..}
across the board for access to properties. One standard way no matter
what plugin you are in.
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Summary
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. So something like:
${plugins.java.maven.compile.target}
doesn't resolve but
${plugins.java.mavenCompileTarget}
does.
So we can either standardize on property names to follow the same
convention as Java variables or come up with a different way to access
properties from external plugins.
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Plugin Summary
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 different directory so that the build files are
distinct from the runtime files. So within a plugin I was thinking just
a slight variation on what Mark suggested and make the directory that
contains the runtime files src/plugin-runtime. So we have something
like:
plugin
project.xml
project.properties
maven.xml
/src
/java
/org ...
/plugin-resources ...
/plugin-runtime
maven.xml
project.properties
/xdocs
This way we have the distinction but can still use the same mechanism
internally. I definitely think this is a great idea.
As far as property accessing within a plugin:
${maven.compile.target}
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 properties.
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Aligning plugin artifacts with normal projects
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 the best idea so far. > 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, > > > > > > 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 suggesting that it's not unheard of for a plugin > > project to use maven.xml and project.properties at build time. I'd have > > thought the obvious solution to make this all more consistent would be > > to move the run-time executable parts of the plugin somewhere under the > > src directory rather than having everything dumped in the project root > > as at the moment: > > > > plugin > > project.xml > > project.properties > > maven.xml > > /src > > /java > > /org... > > /maven > > maven.xml > > project.properties > > /xdocs > > > > This would tighten up the distinction between project metadata and > > build-time stuff (project root) and run-time artifacts (somewhere under > > src). > > > > -Mark. > > > > > > - > > 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] -- jvz. Jason van Zyl [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Aligning plugin artifacts with normal projects
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 a distinction between building the plugin and running the plugin. I jumped the gun a bit. That's why I asked. > -- > 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 07:58:52 AM: > > > 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. > > > > I think this alignment would make explaining plugins work as they now do > > work the same as a normal project. > > > > I can change all the plugins in CVS but admittedly plugins outside the > > ones we store will have to change the file names if we make the change. > > I would like to make the plugins more consistent with normal projects > > for 1.0 if there are no objections. > > > > -- > > jvz. > > > > Jason van Zyl > > [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jvz. Jason van Zyl [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Standard method for retrieving plugin properties in plugins
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 keep
track. After thinking about it I think I like that too.
${maven.compile.target}
${plugins.antlr.src.dir}
If I can get this to work this is what you would prefer, yes?
> -Vincent
>
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > [EMAIL PROTECTED]
> > 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Aligning plugin artifacts with normal projects
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 can leave them separate. As I'm refactoring I'm just popping out questions to users to make sure I don't bonk anyone. > Thanks > -Vincent > > > -Original Message- > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > Sent: 25 June 2003 23:59 > > To: Maven Developers List > > Subject: Aligning plugin artifacts with normal projects > > > > 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. > > > > I think this alignment would make explaining plugins work as they now > do > > work the same as a normal project. > > > > I can change all the plugins in CVS but admittedly plugins outside the > > ones we store will have to change the file names if we make the > change. > > I would like to make the plugins more consistent with normal projects > > for 1.0 if there are no objections. > > > > -- > > jvz. > > > > Jason van Zyl > > [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Aligning plugin artifacts with normal projects
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, > > > > 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 suggesting that it's not unheard of for a plugin > project to use maven.xml and project.properties at build time. I'd have > thought the obvious solution to make this all more consistent would be > to move the run-time executable parts of the plugin somewhere under the > src directory rather than having everything dumped in the project root > as at the moment: > > plugin > project.xml > project.properties > maven.xml > /src > /java > /org... > /maven > maven.xml > project.properties > /xdocs > > This would tighten up the distinction between project metadata and > build-time stuff (project root) and run-time artifacts (somewhere under > src). > > -Mark. > > > - > 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]
[jira] Created: (MAVEN-520)
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:
-
Key: MAVEN-520
Summary:
Maven says single = ${single}.
Is single empty? Maven says [${empty single}].
Maven says two.levels = ${two.levels}.
Is two.levels empty? Maven says [${empty two.levels}].
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-519) NekoHTML 0.7.7 upload request
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: - Key: MAVEN-519 Summary: NekoHTML 0.7.7 upload request Type: Task Status: Unassigned Priority: Major Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Assignee: Reporter: Mike Bowler Created: Thu, 26 Jun 2003 6:07 AM Updated: Thu, 26 Jun 2003 6:07 AM Description: Please add NekoHTML 0.7.7 to the repository. It can be found at http://www.apache.org/~andyc/neko/doc/html/index.html - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Aligning plugin artifacts with normal projects
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 suggesting that it's not unheard of for a plugin project to use maven.xml and project.properties at build time. I'd have thought the obvious solution to make this all more consistent would be to move the run-time executable parts of the plugin somewhere under the src directory rather than having everything dumped in the project root as at the moment: plugin project.xml project.properties maven.xml /src /java /org... /maven maven.xml project.properties /xdocs This would tighten up the distinction between project metadata and build-time stuff (project root) and run-time artifacts (somewhere under src). -Mark. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deploy API (artifact plugin)
> -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, that *really* looks good... > > > #list of repositories to which we will deploy > > maven.repo.repos= R1, R2, R3, R4, ibiblio > > Is there really need for this property? > I am just afraid of users forgetting to add to this property which will > raise question on the mailinglist > > Possible reaons from my point of view: > > a) convenience for Michal :-) > He does not need to loop over all properties check for a maven.repo.* > match... > 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 in parent project, And you should not be aware of them. But you are 100% right that it should be simpler. That's why I asked for comments, hoping that somebody will have an idea how to simplify. BTW: It's even more complicated then I have described last time. Silently I assume existence of default (central repository). Some setting of this repository are matching Tags in POM This repository is silently named "central". It's clear that in POM there is no place for some properties of this repository (like username, password, passpharse of private key, proxy host etc). Other settings used this repository are currently described in (BTW: why they are there? It's very hard to find them!) http://maven.apache.org/reference/plugins/jar/properties.html Namely: maven.repo.central maven.repo.central.directory maven.username maven.remote.group I will try to hack my code to make it backward compatible ... but among those settings you won't find e.g. user's password. I need to know it. :( For the moment using my (poor!!) naming convention you can use: #(don't have to use it if tag was used in POM maven.repo.central=www.apache.org #(don't have to use it if tag was used) maven.repo.central.directory= maven.repo.central.username maven.repo.central.group maven.repo.central.password maven.repo.central.passphrase maven.repo.central.privatekey maven.repo.central.port maven.repo.central.proxy.host maven.repo.central.proxy.port maven.repo.central.proxy.username maven.repo.central.proxy.password I think that it is more consistent...but way too complicated. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Aligning plugin artifacts with normal projects
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: Aligning plugin artifacts with normal projects
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.
I have exactly the same doubts.
I think we should go step further and get rid of plugin.properties file...
in favour of metadata file.
It can look like:
foo
baa
foo
maven-foo-plugin
So when plugin is loaded all properties (native and imported from another
plugins)are directly accessibly in it's context.
So we even don't need:
${plugin.getProperty('maven.compile.target')} ---> ${maven.compile.target}
or
${pom.getPluginContext('maven-foo-plugin').getVariable('bar')} --> ${foo}
There is one problem here: some goal's might not need some properties, so
loading them while plugin starts might be expensive.
We I hope we can find solution for that.
It is much simpler then what you have proposed and more powerful
BTW: We anyway need plugin metadata file which can be used by IDEs.
Michal
-
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]
Re: Aligning plugin artifacts with normal projects
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 ask 'what property do I set to do' because there are so many undocumented properties. If there was a metadata file that described plugin properties, it could be used to generate the xdocs. However it isn't just plugins that need this - normal projects use additional properties to configure things in their maven.xml. So properties should appear as a standard report. -Baz Privacy and Confidentiality Notice The information contained in this E-Mail message is intended only for the person or persons to whom it is addressed. Such information is confidential and privileged and no mistake in transmission is intended to waive or compromise such privilege. If you have received it in error, please destroy it and notify us on the telephone number printed above. If you do not receive complete and legible copies, please telephone us immediately. Any opinions expressed herein including attachments are those of the author only. i-documentsystems Ltd. does not accept responsibility for the accuracy or completeness of the information provided or for any changes to this Email, however made, after it was sent. (Please note that it is your responsibility to scan this message for viruses). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Aligning plugin artifacts with normal projects
> -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
> exposes and those it uses for it's own purposes? The plugin plugin uses
> plugin.properties to generate docs.
I have exactly the same doubts.
I think we should go step further and get rid of plugin.properties file...
in favour of metadata file.
It can look like:
foo
baa
foo
maven-foo-plugin
So when plugin is loaded all properties (native and imported from another
plugins)are directly accessibly in it's context.
So we even don't need:
${plugin.getProperty('maven.compile.target')} ---> ${maven.compile.target}
or
${pom.getPluginContext('maven-foo-plugin').getVariable('bar')} --> ${foo}
There is one problem here: some goal's might not need some properties, so
loading them while plugin starts might be expensive.
We I hope we can find solution for that.
It is much simpler then what you have proposed and more powerful
BTW: We anyway need plugin metadata file which can be used by IDEs.
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Results of clean bootstrap at 20030626-0317
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/plugins-build/xdoc/src/plugin-resources/images/strich.gif U maven/src/plugins-build/xdoc/src/plugin-resources/images/sw_min.gif U maven/src/plugins-build/xdoc/src/plugin-resources/images/update.gif cvs server: Updating maven/src/plugins-build/xdoc/src/plugin-resources/images/logos U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-bolt.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-brewed.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-build-successfull.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-built.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-bulldozer.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-1.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-2.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-3.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-4.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-5.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-black.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-blue.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-copper.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-green.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-pinky.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-purple.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-button-teal.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-feather.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-frankenstein.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-mavenfactured.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-petesucks.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-propaganda-2.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-propaganda.png U maven/src/plugins-build/xdoc/src/plugin-resources/images/logos/maven-redgreen.png cvs server: Updating maven/src/plugins-build/xdoc/src/plugin-resources/jelly-templates U maven/src/plugins-build/xdoc/src/plugin-resources/jelly-templates/cvs-usage.xml U maven/src/plugins-build/xdoc/src/plugin-resources/jelly-templates/dependencies.xml U maven/src/plugins-build/xdoc/src/plugin-resources/jelly-templates/index.xml U maven/src/plugins-build/xdoc/src/plugin-resources/jelly-templates/issue-tracking.xml U maven/src/plugins-build/xdoc/src/plugin-resources/jelly-templates/mail-lists.xml U maven/src/plugins-build/xdoc/src/plugin-resources/jelly-templates/maven-reports.xml U maven/src/plugins-build/xdoc/src/plugin-resources/jelly-templates/project-info.xml U maven/src/plugins-build/xdoc/src/plugin-resources/jelly-templates/team-list.xml cvs server: Updating maven/src/plugins-build/xdoc/src/plugin-resources/templates U maven/src/plugins-build/xdoc/src/plugin-resources/templates/cvs-usage.xml U maven/src/plugins-build/xdoc/src/plugin-resources/templates/dependencies.xml U maven/src/plugins-build/xdoc/src/plugin-resources/templates/index.xml U maven/src/plugins-build/xdoc/src/plugin-resources/templates/issue-tracking.xml U maven/src/plugins-build/xdoc/src/plugin-resources/templates/mail-lists.xml U maven/src/plugins-build/xdoc/src/plugin-resources/templates/maven-reports.xml U maven/src/plugins-build/xdoc/src/plugin-resources/templates/project-info.xml U maven/src/plugins-build/xdoc/src/plugin-resources/templates/team-list.xml cvs server: Updating maven/src/plugins-build/xdoc/src/test U maven/src/plugins-build/xdoc/src/test/.cvsignore U maven/src/plugins-build/xdoc/src/test/project.properties U maven/src/plugins-build/xdoc/src/test/project.xml cvs server: Updating maven/src/plugins-build/xdoc/src/test/org cvs server: Updating maven/src/plugins-build/xdoc/src/test/org/apache cvs server: Updating maven/src/plugins-build/xdoc/src/test/org/apache/maven U maven/src/plugins-build/xdoc/src/test/org/apache/maven/NavBeanTest.java cvs server: Updating maven/src/plugins-build/xdoc/src/test/xdocs U maven/src/plugins-build/xdoc/src/test/xdocs/index.xml U maven/src/plugins-build/xdoc/src/test/xdocs/navigation.xml cvs server: Updating maven/src/plugins-build/xdoc/src/test/xdocs/alpha U maven/src/plugins-build/xdoc/src/test/xdocs/alpha/index.xml cvs server: Updating maven/src/plugins-build/xdoc/src/test/xdocs/alpha/one U maven
RE: multiple source directories... my turn... :-)
> -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 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.
Oh no, you're right, but I'll just need to override the maven.final.name
property for that I think.
Thanks
-Vincent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Aligning plugin artifacts with normal projects
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple source directories... my turn... :-)
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,
Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Aligning plugin artifacts with normal projects
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 one provide server and channelname? Forgive me if it's somewhere documented... Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiple source directories... my turn... :-)
> -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.version}"/>
>
>
>
> refid="maven.j2ee.compile.src.set"/>
>
ah yeah, I had forgotten about that. Thanks Brett.
>
> 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.
Not sure why.
>
> I'm not sure how it works out with tests though - you could check that
> it is using a set for its compiles as well.
>
> Ideally here I think you have framework-shared.jar,
framework-j2ee12.jar
> and framework-j2ee13.jar.
That is too complex for end users I think. It's much easier that they
get a single framework-${j2ee.version}.jar jar to put in their
classpath.
Yeah, I know, you're going to tell me I could then use the uberjar
plugin in a top level project to perform the merge... ;-)
Thanks
-Vincent
>
> - Brett
>
> Vincent Massol wrote:
> > Hi,
> >
> > We are trying to Mavenize the cactus build and Cactus has the
following
> > directory structure for the framework subproject:
> >
> > framework
> > |_ src
> > |_ java
> > |_ j2ee12 (j2ee 1.2 specific source code)
> > |_ j2ee13 (j2ee 1.3 specific source code)
> > |- share (source code common to j2ee 1.2 and 1.3)
> > |_ test
> > |_ j2ee12
> > |_ j2ee13
> > |- share
> > [...]
> >
> > This is really one source tree in practice but split over different
> > directories as we need to support different APIs.
> >
> > I can see 3 solutions but I don't like them:
> >
> > Solution 1: Create 3 framework projects
> >
> > framework-share/
> > framework-j2ee12/
> > framework-j2ee13/
> >
> > Solution 2: Use a preGoal in maven.xml to copy the files to a common
> > location.
> >
> > I prefer solution 2 but what I don't like is that it involves an
extra
> > copying step which will slow the build even more (and it's already
> > taking 18 minutes for a full Cactus build with Ant - not just the
> > framework project of course).
> >
> > Solution 3: Put everything in the same source tree, use factory
classes
> > and reflection, with some tricks to make sure some classes are not
> > loaded in memory when the J2EE version is not the correct one. At
this
> > point in time, this is really too complex and I'm not even sure it
is
> > the right approach. The current solution is more tailored to a
specific
> > need. If I'm working with J2EE 1.3, I don't care about J2EE 1.2 for
> > example.
> >
> > Are there any other solutions that I'm not aware of?
> >
> > Isn't this a valid case?
> >
> > I'm not sure what codeswitcher is. Would it help?
> >
> > Thanks
> > -Vincent
> >
> >
> >
-
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Web Developer
> f2 network ~ everything essential
> 02 8596 4437
>
>
> -
> 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]
Re: multiple source directories... my turn... :-)
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 set for its compiles as well. Ideally here I think you have framework-shared.jar, framework-j2ee12.jar and framework-j2ee13.jar. - Brett Vincent Massol wrote: Hi, We are trying to Mavenize the cactus build and Cactus has the following directory structure for the framework subproject: framework |_ src |_ java |_ j2ee12 (j2ee 1.2 specific source code) |_ j2ee13 (j2ee 1.3 specific source code) |- share (source code common to j2ee 1.2 and 1.3) |_ test |_ j2ee12 |_ j2ee13 |- share [...] This is really one source tree in practice but split over different directories as we need to support different APIs. I can see 3 solutions but I don't like them: Solution 1: Create 3 framework projects framework-share/ framework-j2ee12/ framework-j2ee13/ Solution 2: Use a preGoal in maven.xml to copy the files to a common location. I prefer solution 2 but what I don't like is that it involves an extra copying step which will slow the build even more (and it's already taking 18 minutes for a full Cactus build with Ant - not just the framework project of course). Solution 3: Put everything in the same source tree, use factory classes and reflection, with some tricks to make sure some classes are not loaded in memory when the J2EE version is not the correct one. At this point in time, this is really too complex and I'm not even sure it is the right approach. The current solution is more tailored to a specific need. If I'm working with J2EE 1.3, I don't care about J2EE 1.2 for example. Are there any other solutions that I'm not aware of? Isn't this a valid case? I'm not sure what codeswitcher is. Would it help? Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Web Developer f2 network ~ everything essential 02 8596 4437 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
