>
>
> I would avoid the command line passed password. It is much less secure
> on unix than the password kept in a file. Command line can be seen by
> simple ps commands, or e.g. linux systems store the in the /proc
> filesystem.
> It should be used only from command files.
>
> incze
>
I want to
> BTW:
>
> For the moment I have tested my API with username, user password
> kept in properties file. I think such approach is not acceptable.
>
> You can use command line to pass properties to maven:
>
> maven war:deloy -Dmaven.repo.ibiblio.password = **
>
>
> This is already better
Hi,
If people have come into contact with Werkz via Maven are interested in
its development a list has been setup:
http://lists.codehaus.org/mailman/listinfo/werkz-interest
I'm going to be making modifications so if anyone is using it and wants
to keep abreast of changes join the mailing list.
Hi,
Just a little update on some of the refactoring that is going on.
Probably one of the most important things that I've eliminated is the
memory leak. This was being caused by a few things: one was the creation
of an Ant project and Jelly Context for each project that was
instantiated, the inte
On Fri, 2003-06-27 at 09:19, Michal Maczka wrote:
> +1
>
> > As far as the structure of the plugin, I propose what Mark H. Wilkinson
> > suggested where we use different directories to distinguish between
> > build time and runtime. So the structure would look something like:
> >
> >
> >sr
> aggregate:build, aggregate:site [3]
aggregator?
mm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Rafal Krzewski wrote:
I admit that having reactor tag (backed by reactor bean) and reactor
plugin may be confusing. Still I don't see any compelling alternative.
How about giving it a different name that new users would recognize? The
'reactor' is something people only learn about by reading th
Dion!
I just looked at your description ... you already did it!
Great!
Michal
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 27, 2003 10:18 AM
> To: 'Maven Developers List'
> Subject: RE: New 'reactor' plugin
>
> I also need it!
>
> Just in c
> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 27, 2003 3:08 PM
> To: Maven Developers List
> Subject: Plugin Summary
>
> Hi,
>
> I'll do the Plugin Summary again as a few people missed it and I
> probably didn't explain myself clearly.
>
> As
On Fri, 2003-06-27 at 08:55, Rafal Krzewski wrote:
> Jason van Zyl wrote:
> > On Fri, 2003-06-27 at 03:19, [EMAIL PROTECTED] wrote:
> >
> >>I've just added this plugin as it has come in handy when working with
> >>multiple projects in my day job.
> >
> >
> > How is this different than the stand
Hi,
I'll do the Plugin Summary again as a few people missed it and I
probably didn't explain myself clearly.
As far as plugin property access I am proposing:
${plugins.}
Across the board in all plugins for values even for values that belong
to a particular plugin. So something like:
${plugins.
Jason van Zyl wrote:
> On Fri, 2003-06-27 at 03:19, [EMAIL PROTECTED] wrote:
>
>>I've just added this plugin as it has come in handy when working with
>>multiple projects in my day job.
>
>
> How is this different than the standard reactor? Please don't name it
> the reactor as having two entit
On Fri, 2003-06-27 at 08:47, Jason van Zyl wrote:
> I can deal with our plugins, but for the sake of a sane 1.0 release and
> something we can easily document I think this is the right way to go. I
> added the cross plugin access at one point for Vincent and I admittedly
> did it to quickly. But I
On Fri, 2003-06-27 at 03:18, Rafal Krzewski wrote:
> Jason van Zyl wrote:
>
> > 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 t
On Fri, 2003-06-27 at 02:18, [EMAIL PROTECTED] wrote:
> If we don't have to rejig the properties for all the plugins, I'm +1 on
> the new dotted syntax.
The standard syntax would be more namespace sensible in the form of:
${plugins.antlr.srcDir}
And without changing the names you can't do it wi
On Fri, 2003-06-27 at 03:19, [EMAIL PROTECTED] wrote:
> I've just added this plugin as it has come in handy when working with
> multiple projects in my day job.
How is this different than the standard reactor? Please don't name it
the reactor as having two entities with the same name will be conf
> > 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 ca
[EMAIL PROTECTED] wrote:
>>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.
>
I also need it!
Just in case you find it useful/worthed to put to this plugin:
I often use such "generic" goal (bit modified here, hope that it still
works)
Then from command line
maven reactor:for-all -Dgoals=jar:install-snapshot
I find it very useful.
Michal
> -Origin
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 27, 2003 6:16 AM
> To: Maven Developers List
> Subject: RE: Deploy API (artifact plugin)
>
> I think I've asked this before, but AFAIK,
>
> distributionSiteare not related AT ALL to
> maven.rep
[EMAIL PROTECTED] wrote:
> I've just added this plugin as it has come in handy when working with
> multiple projects in my day job.
>
> I haven't yet add the site aggregation I was hoping to have done by now.
>
> The plan is to allow for multiple strategies for implementing site
> aggregation:
Last 500 lines of a clean bootstrap build of maven at 20030627-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
Jason van Zyl wrote:
> 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 classloade
I've just added this plugin as it has come in handy when working with
multiple projects in my day job.
I haven't yet add the site aggregation I was hoping to have done by now.
The plan is to allow for multiple strategies for implementing site
aggregation:
1) independent sites, ala db.apache.org
24 matches
Mail list logo
