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
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
--
Martin Skopp
Rieg
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 ad
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.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.mult
> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: 26 June 2003 04:07
> To: Maven Developers List
> Subject: Re: Standard method for retrieving plugin properties in
plugins
>
> On Wed, 2003-06-25 at 20:47, Jason van Zyl wrote:
> > Hi,
> >
> > Just glancing aroun
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?
Thanks
-Vincent
> -Original Message-
> From: Jason van Zyl [
out of these I prefer
as you can probably do better error reporting and it is clearer what is
the plugin and what is the property.
- Brett
Jason van Zyl wrote:
On Wed, 2003-06-25 at 20:47, Jason van Zyl wrote:
Another thing would probably be nice to standardize is the inter-plugin
property ret
Is this your maven.xml that is using the interaction tag library from
jelly? If you are then you need to declare it as a dependency.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
"Matthew Wilson" <[EMAIL PROTECTED]>
On Thu, 26 Jun 2003 12:07 pm, Jason van Zyl wrote:
>
>
> so that would extract the 'maven.dest.dir' property from the xdoc plugin
> and place the value in 'dest.dir' for use in the current context.
Sounds good. But it may be better to name the attributes more according to
what they do or else yo
Jason,
Are you saying ${plugin.getProperty('maven.compile.target')} for the
current plugin, and
${pom.getPlugin('maven-foo-plugin').getProperty('bar')} for another plugin?
Sounds good to me.
That leaves ant propertys and j:set values to be the only ones
referenced as ${foo.bar}, right?
Cheer
On Wed, 2003-06-25 at 20:47, Jason van Zyl wrote:
> Hi,
>
> Just glancing around the plugins I see a few different ways that people
> are using to reference plugin properties that belong to the plugin in
> question. For example inside the java plugin there are references like:
>
> ${maven.compile
Hi,
Just glancing around the plugins I see a few different ways that people
are using to reference plugin properties that belong to the plugin in
question. For example inside the java plugin there are references like:
${maven.compile.target}
${context.getVariable('maven.compile.fork'}
and in som
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
Michal Maczka wrote:
> I have progressed with Deployer API.
Good to hear that. Incosistency among plugins in this regard was a
big drawback IMO.
Everything looks good, but...
#list of repositories to which we will deploy
maven.repo.repos= R1, R2, R3, R4, ibiblio
^
maven.repo.lis
michal 2003/06/25 08:25:19
Modified:src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
FtpDeployer.java SFtpDeployer.java ScpDeployer.java
FileDeployer.java HttpDeployer.java
GenericSshDeployer.ja
I have progressed with Deployer API.
To make it clear - we have actually 3 types of repositories:
local (single instance)
remote-readonly
remote-writable
Maven can now deploy to many remote repositories.
Deployers are just simple one shoot file copiers - See:
org.apache.maven.deploy.
Vincent Massol wrote:
Hi Ben,
Cool, but why don't you use the Apache Wiki? :-) Actually, I don't
really care which wiki we use but I think it's better to use only one.
I hate usemod (it's ugly, it's primitive, it's limited). Up until now it
was a means to an end. We've now got something bette
michal 2003/06/25 05:33:11
Modified:src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
SFtpDeployer.java
src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
MavenDeployRequest.java
Team,
Every time I build from the head; I get the following stacktrace
when I run the built maven. Is this dependency not downloaded with the
rest?
2003-06-25 07:33:50,375 ERROR org.apache.commons.jelly.JellyContext - Could
not find the class:
org.apache.commons.jelly.tags.interaction.Int
Hi Ben,
Cool, but why don't you use the Apache Wiki? :-) Actually, I don't
really care which wiki we use but I think it's better to use only one.
Also, I think it is duplicate information from the one found in
project.xml.
Why don't we instead generate a page on
http://maven.apache.org/referenc
> SCP has really pure functionality comparing to SFTP.
I wanted to write poor. (Spell checkers:) )
mm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
See http://wiki.codehaus.org/general/Maven_2fPluginOwners
I'll aggregate the 3 emails on this already, but all additional bits
should probably go in the wiki directly.
This email was out of control :)
Vincent Massol wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PR
I'm interested in the comments on CPD/Simian performance - since I was
responsible for the current algorithm in CPD. On my dodgy old 833MHz
laptop, CPD does the entire JDK1.4 in about 1 minute 30, all but 18
seconds of which are actually spent reading the files (ok reading the
files and buildin
Michal Maczka wrote:
>>I really don't appreciate this kind of name reuse - sftp is a protocol
>>registered by the IETF (tcp/115). It was rather silly of JCraft to use
>>that name for their scp implementation. Let's do better than them and
>>have JavaScpDeployer (and possibly ExternalScpDeployer, if
> I really don't appreciate this kind of name reuse - sftp is a protocol
> registered by the IETF (tcp/115). It was rather silly of JCraft to use
> that name for their scp implementation. Let's do better than them and
> have JavaScpDeployer (and possibly ExternalScpDeployer, if we want to
> keep it
Last 500 lines of a clean bootstrap build of maven at 20030625-0300
U maven/src/plugins-build/xdoc/src/plugin-resources/images/help_logo.gif
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
26 matches
Mail list logo
