RE: Deploy API (artifact plugin)
> -Original Message- > From: Rafal Krzewski [mailto:[EMAIL PROTECTED] > Sent: Monday, June 30, 2003 11:17 AM > To: Maven Developers List > Subject: Re: Deploy API (artifact plugin) > > Michal Maczka wrote: > > > 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 ... but still not perfect. > > > > I will try to implement/use(if I find one) simple "Prompter" which will > ask > > to type your password (eventually to enter other required parameters > which > > are missing) > > The best approach to the problem is IMO using an ssh agent program. > Under unix, you can check for SSH_AGENT_PID and SSH_AUTH_SOCK > environment variables to find the information about the program you > should talk to. I don't know if the JCraft ssh stuff can talk to > an agent though. > Don't think so. JSch is autonomous library. > I also hear that there is an ssh agent (or ssh agent like, because > of the obvious lack of unix sockets) for the M$ Windows, distributed > as a part of the excelent PuTTY package. > > This is definetly the most interesting solution as it enables PKI > authentication, and lifts the burden of asking for passwords from the > application) > PKI authentication also supported by JSch and is in my code. You also need to provide a password (passphrase) for private key file. Like in http://www.tartarus.org/~simon/puttydoc/Chapter8.html#8 So basically Maven takes over the role of "Pageant" in this process. The problem is that Pageant is long-living process while maven is not. If somebody will find it is necessary we can think to implement Command-line deployer which when asked to deploy a file will basically start a new process (can be a batch file, executable program etc...). This will be backward compatible with old conception of deploying artifacts and will give the same flexibility of setting up the security infrastructure outside of Maven. It's an old truth: Either something is secure or is easy to use. I wanted to make it easier to use. My main idea was: the most of the people are using MS Windows. I want to give them easy (out-of-the box) access to such ordinary task (from maven perspective) as deployment of artifact to remote repository so they don't need to install any external programs. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deploy API (artifact plugin)
Michal Maczka wrote: > 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 ... but still not perfect. > > I will try to implement/use(if I find one) simple "Prompter" which will ask > to type your password (eventually to enter other required parameters which > are missing) The best approach to the problem is IMO using an ssh agent program. Under unix, you can check for SSH_AGENT_PID and SSH_AUTH_SOCK environment variables to find the information about the program you should talk to. I don't know if the JCraft ssh stuff can talk to an agent though. I also hear that there is an ssh agent (or ssh agent like, because of the obvious lack of unix sockets) for the M$ Windows, distributed as a part of the excelent PuTTY package. This is definetly the most interesting solution as it enables PKI authentication, and lifts the burden of asking for passwords from the application) R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deploy API (artifact plugin)
distributionSite and distributionDirectory are used for 'publishing' the generated site and other artifacts, the central repo is a global space where many projects artifacts are published. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Work: http://www.multitask.com.au Michal Maczka <[EMAIL PROTECTED]> wrote on 27/06/2003 06:12:25 PM: > > > > -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.repo.central. > > > > > Last time you asked: > > " > > maven.apache.org > > /www/maven.apache.org/ > This is the web site address and directory, not a repo???" > > :) > > I was sure that you just wanted to get sure that I use distributionSite and > distributionDirectory. > > > > distributionSite is not described in > http://maven.apache.org/reference/project-descriptor.html > > > While > distributionDirectory: > > Optional. The directory on the web server where the final distributions will > be published. This is used when the distributions are deployed > > (the word deployed is a hyper link which points to "site" plugin) > > > I though that "final distributions" are the distribution of artifacts > delivered by projects: jars, javadoc, project src zipped, > > Now I see I finaly understand that you might want e.g to publish > "distribution" of > entire project at sourceforge... and not to deploy to any repository. > > > > If I am still wrong: can you then explain briefly the difference? > > I want to centralized the code which does remote copying of the files > And I see now that "distribution" requires special handling ... I will/want > to change my code to support it. > > 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 ... but still not perfect. > > I will try to implement/use(if I find one) simple "Prompter" which will ask > to type your password (eventually to enter other required parameters which > are missing) > > regards > > > Michal > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
RE: Deploy API (artifact plugin)
> > > 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 support all 3 possiblites: a)files b)command line parameters c) ask the user to enter the password (this is just plan at the moment) In fact I would need to make tricks to support a) and not to support b) as this is build-in in Maven so I am not going to block this possibility It will be nice to explain in documentaion all security risks. They cleary are platform depended (e..g files containing passwords are bad idea under MS Windows) mm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deploy API (artifact plugin)
> 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 ... but still not perfect. > > I will try to implement/use(if I find one) simple "Prompter" which will ask > to type your password (eventually to enter other required parameters which > are missing) > > regards > > > Michal 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deploy API (artifact plugin)
> -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.repo.central. > Last time you asked: " > maven.apache.org > /www/maven.apache.org/ This is the web site address and directory, not a repo???" :) I was sure that you just wanted to get sure that I use distributionSite and distributionDirectory. distributionSite is not described in http://maven.apache.org/reference/project-descriptor.html While distributionDirectory: Optional. The directory on the web server where the final distributions will be published. This is used when the distributions are deployed (the word deployed is a hyper link which points to "site" plugin) I though that "final distributions" are the distribution of artifacts delivered by projects: jars, javadoc, project src zipped, Now I see I finaly understand that you might want e.g to publish "distribution" of entire project at sourceforge... and not to deploy to any repository. If I am still wrong: can you then explain briefly the difference? I want to centralized the code which does remote copying of the files And I see now that "distribution" requires special handling ... I will/want to change my code to support it. 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 ... but still not perfect. I will try to implement/use(if I find one) simple "Prompter" which will ask to type your password (eventually to enter other required parameters which are missing) regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
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: 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: 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... b) offers the option to define maven.repo.MYUSED.* but not to use it. Nice feature, but I doubt that it's really required... Just my .02 cents > -- > Martin Skopp > Riege Software International GmbH > Support: mailto:[EMAIL PROTECTED], Information: http://www.riege.com > > This email is intended to be viewed with a nonproportional font. > Public Key on http://www.keyserver.net, Key-ID: 3D4027B5 > Fingerprint: 1970 C78D 9A1D 99FA 5CE4 5C0D 29E6 6A95 3D40 27B5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deploy API (artifact plugin)
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.list maybe? R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
