Maven Plugin for IBM portlet deployment
Hi, I'm searching for a maven plugin or an ant task, which is able to install portlets in the ibm websphere portal server 5.0.2.2. Regards Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Best approach to job
I have a simple project which produces a java stand-alone and I need to produce the distribution zip file, and I would like to have a maven goal to do that. I had a look at maven's built-in dist task, and I can see a broad compatibility there with my aims, but there is a large amount of work that it undertakes which I would like to cut out, and a couple of points that I would like to adapt. Maven's documentation makes several references to the Maven way of doing things, such as 'try not to have a maven.xml' and 'it's not recommended to use maven.junit.skip', and wanting to stay in the same paradigm, rather than just coding a big ant script like the old ant developer I am, I'm asking myself what the best approach is. I want to produce a zip containing a directory structure like so: /lib - dependency jars and my jar /bin - shell scripts to launch java /conf - config & property files /log - for output And I would like to avoid running tests and reports and doing a website xdoc build. Any pointers, anyone? Adam http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
RE: Best approach to job
What is your objection to doing the tests, reports, and website? Howe often do you expect to do a distribution? You could code around it, but yes, it would be easier to just go with the flow.. You could run the default dist goal, and then add your own logic after that to stip out the parts you don't need/want... -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 23, 2005 12:20 PM To: Maven Users List Subject: Best approach to job I have a simple project which produces a java stand-alone and I need to produce the distribution zip file, and I would like to have a maven goal to do that. I had a look at maven's built-in dist task, and I can see a broad compatibility there with my aims, but there is a large amount of work that it undertakes which I would like to cut out, and a couple of points that I would like to adapt. Maven's documentation makes several references to the Maven way of doing things, such as 'try not to have a maven.xml' and 'it's not recommended to use maven.junit.skip', and wanting to stay in the same paradigm, rather than just coding a big ant script like the old ant developer I am, I'm asking myself what the best approach is. I want to produce a zip containing a directory structure like so: /lib - dependency jars and my jar /bin - shell scripts to launch java /conf - config & property files /log - for output And I would like to avoid running tests and reports and doing a website xdoc build. Any pointers, anyone? Adam http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best approach to job
> I have a simple project which produces a java stand-alone and I need to > produce the distribution zip file, and I would like to have a maven goal > to do that. > Lets have a look to the distribution plugin: http://maven.apache.org/reference/plugins/dist/ Moreover you can create in your maven.xml ant script (like u said) Regards, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best approach to job
It takes so long on my old 700MHz machine! Later on admittedly I can foresee not doing distributions very often at all so it wouldn't be an issue, but at the moment I might want to try it 5 times in a row. I can easily take out all the reports from my project.xml. Perhaps setting up goals to run them individually would be an alternative, but I've got the website up already (although mostly for my own use). Is there any documentation on the built-in dependencies between goals? I didn't see (or perhaps better said, recognise) any on the maven website. How would I go about stripping out the reports generation then? -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: 23 March 2005 12:26 To: 'Maven Users List' Subject: RE: Best approach to job What is your objection to doing the tests, reports, and website? Howe often do you expect to do a distribution? You could code around it, but yes, it would be easier to just go with the flow.. You could run the default dist goal, and then add your own logic after that to stip out the parts you don't need/want... -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 23, 2005 12:20 PM To: Maven Users List Subject: Best approach to job I have a simple project which produces a java stand-alone and I need to produce the distribution zip file, and I would like to have a maven goal to do that. I had a look at maven's built-in dist task, and I can see a broad compatibility there with my aims, but there is a large amount of work that it undertakes which I would like to cut out, and a couple of points that I would like to adapt. Maven's documentation makes several references to the Maven way of doing things, such as 'try not to have a maven.xml' and 'it's not recommended to use maven.junit.skip', and wanting to stay in the same paradigm, rather than just coding a big ant script like the old ant developer I am, I'm asking myself what the best approach is. I want to produce a zip containing a directory structure like so: /lib - dependency jars and my jar /bin - shell scripts to launch java /conf - config & property files /log - for output And I would like to avoid running tests and reports and doing a website xdoc build. Any pointers, anyone? Adam http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best approach to job
Hi Adam, basically you have two choices +) buy a new box - I thin 3.000MHz are affordable ... ;-) +) checkout the docs about using the section in the project.xml Cheers, Siegfried Goeschl Adam Hardy wrote: It takes so long on my old 700MHz machine! Later on admittedly I can foresee not doing distributions very often at all so it wouldn't be an issue, but at the moment I might want to try it 5 times in a row. I can easily take out all the reports from my project.xml. Perhaps setting up goals to run them individually would be an alternative, but I've got the website up already (although mostly for my own use). Is there any documentation on the built-in dependencies between goals? I didn't see (or perhaps better said, recognise) any on the maven website. How would I go about stripping out the reports generation then? -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: 23 March 2005 12:26 To: 'Maven Users List' Subject: RE: Best approach to job What is your objection to doing the tests, reports, and website? Howe often do you expect to do a distribution? You could code around it, but yes, it would be easier to just go with the flow.. You could run the default dist goal, and then add your own logic after that to stip out the parts you don't need/want... -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 23, 2005 12:20 PM To: Maven Users List Subject: Best approach to job I have a simple project which produces a java stand-alone and I need to produce the distribution zip file, and I would like to have a maven goal to do that. I had a look at maven's built-in dist task, and I can see a broad compatibility there with my aims, but there is a large amount of work that it undertakes which I would like to cut out, and a couple of points that I would like to adapt. Maven's documentation makes several references to the Maven way of doing things, such as 'try not to have a maven.xml' and 'it's not recommended to use maven.junit.skip', and wanting to stay in the same paradigm, rather than just coding a big ant script like the old ant developer I am, I'm asking myself what the best approach is. I want to produce a zip containing a directory structure like so: /lib - dependency jars and my jar /bin - shell scripts to launch java /conf - config & property files /log - for output And I would like to avoid running tests and reports and doing a website xdoc build. Any pointers, anyone? Adam http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. - 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: Best approach to job
It seems from the list archvies that I'm not the only one coming here with such questions. 'dist' is a popular token. Have the committers thought about expanding the maven dist plugin to give more flexibility? Or is it seen as potential trouble-spot that's best kept nailed down to the config it has now? The number of different factors that could be considered when opening up dist is large: file type, project type, internal directory structure, inclusion of dependency jars etc are just a couple that interested me. -Original Message- From: Adam Hardy Sent: 23 March 2005 12:57 To: 'Maven Users List' Subject: RE: Best approach to job It takes so long on my old 700MHz machine! Later on admittedly I can foresee not doing distributions very often at all so it wouldn't be an issue, but at the moment I might want to try it 5 times in a row. I can easily take out all the reports from my project.xml. Perhaps setting up goals to run them individually would be an alternative, but I've got the website up already (although mostly for my own use). Is there any documentation on the built-in dependencies between goals? I didn't see (or perhaps better said, recognise) any on the maven website. How would I go about stripping out the reports generation then? -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: 23 March 2005 12:26 To: 'Maven Users List' Subject: RE: Best approach to job What is your objection to doing the tests, reports, and website? Howe often do you expect to do a distribution? You could code around it, but yes, it would be easier to just go with the flow.. You could run the default dist goal, and then add your own logic after that to stip out the parts you don't need/want... -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 23, 2005 12:20 PM To: Maven Users List Subject: Best approach to job I have a simple project which produces a java stand-alone and I need to produce the distribution zip file, and I would like to have a maven goal to do that. I had a look at maven's built-in dist task, and I can see a broad compatibility there with my aims, but there is a large amount of work that it undertakes which I would like to cut out, and a couple of points that I would like to adapt. Maven's documentation makes several references to the Maven way of doing things, such as 'try not to have a maven.xml' and 'it's not recommended to use maven.junit.skip', and wanting to stay in the same paradigm, rather than just coding a big ant script like the old ant developer I am, I'm asking myself what the best approach is. I want to produce a zip containing a directory structure like so: /lib - dependency jars and my jar /bin - shell scripts to launch java /conf - config & property files /log - for output And I would like to avoid running tests and reports and doing a website xdoc build. Any pointers, anyone? Adam http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ejb goal
Hi. I am facing a problem with ejb jars that are not packed with their generated ejb-jar.xml. It looks so bluntly weird that I bet someone has seen this before. I'll be glad for any help. BTW does anyone prefer calling the ant ejb task from maven.xml as a replacement ? ___ Daniel Or
Args in goals
Hi,
Does anyone know if there are plans to allow passing arguments when calling goals? For instance, I have to run the same goal for each item in a list. It would be nice to be able to pass the item as argument and get some result back, similar to a jelly invoke call... Something like:
Current item: ${theResult}
...
But more useful...
Thanks,
Steve
Re: Args in goals
Steve Molloy wrote:
Hi,
Does anyone know if there are plans to allow passing arguments when
calling goals? For instance, I have to run the same goal for each item
in a list. It would be nice to be able to pass the item as argument and
get some result back, similar to a jelly invoke call... Something like:
Current item: ${theResult}
...
But more useful. <> .. ;-)
Thanks,
Steve
Don't use a goal, create a new tag.
<... whatever tasks you need to do...>
Parameter passing is unstructured, untyped. In the above, in the
definition of "myOperation" one would refer to the parameter as a Jelly
expression, i.e. "${theItem}"
Examine the sources of some of the plugins for more details.
--
Erik Husby
Senior Software Engineer
Broad Institute of MIT and Harvard
Rm. 2192 320 Charles St, Cambridge, MA 02141-2023
mobile: 781.354.6669, office: 617.258.9227,
email: [EMAIL PROTECTED] AIM: ErikAtBroad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Problem deploying to remote repository an artifact that already exists
Hi, all, I've been facing a problem when Maven tries to deploy to remote
repository an artifact that already exists. I'm using Maven 1.02 and here are
the master project properties:
# Remote Repository Properties ===
maven.repo.remote=http://laranjeiras:8080/reporemoto
maven.repo.remote.enabled=true
#list of repositories to which we will deploy.
#There are 1 repository
maven.repo.list= CTPREPO
#settings for repository 'CTPREPO'
maven.repo.CTPREPO=ftp://laranjeiras
maven.repo.CTPREPO.username=${reporemuser}
maven.repo.CTPREPO.password=${reporempwd}
maven.repo.CTPREPO.directory=tomcat/webapps/maven
The followind messages are part of Mavenlog:
227 Entering Passive Mode (172,20,238,32,213,118).
STOR ftpcetip-R1_0.pom
550 ftpcetip-R1_0.pom: Overwrite permission denied
Failed to deploy to: CTPREPO Reason: Error executing FTP command
org.apache.maven.deploy.exceptions.TransferFailedException: Error
executing FTP command
Thanks in advance for help.
Roberto de Castro
Analista de Suporte
Cetip - Desus Rio de Janeiro
+55 21 2276-7439
mailto:[EMAIL PROTECTED]
Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s)
acima
identificado(s), podendo conter informações e/ou documentos
confidencias/privilegiados e seu sigilo é protegido por lei.
Caso você tenha recebido por engano, por favor, informe o remetente e apague-a
de
seu sistema.
Notificamos que é proibido por lei a sua retenção, disseminação, distribuição,
cópia ou
uso sem expressa autorização do remetente.
Opiniões pessoais do remetente não refletem, necessariamente, o ponto de vista
da
CETIP, o qual é divulgado somente por pessoas autorizadas.
Attention: This message was sent for exclusive use of the addressees above
identified, being able to contain information and or privileged/confidential
documents
and law protects its secrecies.
In case that you it has received for deceit, please, it informs the shipper and
erases it
of your system.
We notify that law forbids its retention, dissemination, distribution, copy or
use without
express authorization.
Personal opinions of the shipper do not reflect, necessarily, the point of view
of the
CETIP, which is only divulged by authorized people.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem deploying to remote repository an artifact that already exists
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 23, 2005, at 15:21, Roberto Castro wrote: Hi, all, I've been facing a problem when Maven tries to deploy to remote repository an artifact that already exists. I'm using Maven 1.02 and here are the master project properties: [snip] The followind messages are part of Mavenlog: 227 Entering Passive Mode (172,20,238,32,213,118). STOR ftpcetip-R1_0.pom 550 ftpcetip-R1_0.pom: Overwrite permission denied Failed to deploy to: CTPREPO Reason: Error executing FTP command org.apache.maven.deploy.exceptions.TransferFailedException: Error executing FTP command Check the file permissions on the artifact in the remote repository. It looks like the user you're using to deploy the artifact doesn't have the correct permissions to overwrite the file. - -- Craig S. Cottingham [EMAIL PROTECTED] OpenPGP key available from: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7977F79C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCQeCTEJLQ3Hl395wRAsFJAJ9s+j2gL/hpveHo56sT9LLdUcXtoQCfWIYm O9/C3rwdKeIkIwCEf8NdDro= =Pec7 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven log4j
Hi all, Is there a way I can log the failure of java:compile into a log file. If so how can I do this? Any help on this would be appreciated. Thanks in advance, Jayaram Confidentiality Statement: This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by return email.
maven roadmap - should i stay or should i go
Hi all, In a project I am currently working on - which is just about to start with the construction phase - we are considering to use maven. I have been encountering maven in previous projects as well and based on these experiences i was quite sure I will use it on many others as well. However when i see the new roadmap description on maven site : <>, i am having doubts on what exactly should we do right now. To take off with the current release (1.0.2) and wait for a complete rewrite of our build scripts? How "complete" will that rewrite actually have to be? All what the explanation in the roadmap leaves us with is a bit of hope that attempts will be made to stay backward compatible in the new 2.0 release. What about the "conceptual approach", how many things can we expect to be different, new or completely dissapear (multiproject, repository, ...goals)? Could someone point me to a document/person that can give a bit more of vision/explanation concerning these issues? What would you suggest to a project that is just about to jump into maven? Thanks. -Sejo
Re: ejb goal
On Wed, 23 Mar 2005 19:18:46 +0200, Daniel Or <[EMAIL PROTECTED]> wrote:
> Hi.
Hello,
> I am facing a problem with ejb jars that are not packed with their
> generated ejb-jar.xml.
You generate tour ejb-jar.xml file with xdoclet ?
In this case, you must specify the ejb plugin where to find your
resource files, using the maven.ejb.src property, for example :
maven.ejb.src=${maven.build.dir}/xdoclet/ejb/
> BTW does anyone prefer calling the ant ejb task from maven.xml as a
> replacement ?
Not for me :-)
--
Thomas Recloux
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven roadmap - should i stay or should i go
Hi Sejo, I'd personally go ahead with Maven 1.0.2. There should be a Maven 1.1 version before this summer too with several components from Maven2 backported. I believe the Maven2 team will make it as easy as possible for existing Maven users to switch to Maven2. Most of the Maven1 concepts will stay but will be implemented differently (new POM version for example). I'll let the Maven2 team comment further on details. -Vincent > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: jeudi 24 mars 2005 08:22 > To: Maven Users List > Subject: maven roadmap - should i stay or should i go > > Hi all, > > In a project I am currently working on - which is just about to start with > the construction phase - we are considering to use maven. I have been > encountering maven in previous projects as well and based on these > experiences i was quite sure I will use it on many others as well. > > However when i see the new roadmap description on maven site : > > < with any of the Maven 1.x releases>>, > > i am having doubts on what exactly should we do right now. > > To take off with the current release (1.0.2) and wait for a complete > rewrite of our build scripts? How "complete" will that rewrite actually > have to be? All what the explanation in the roadmap leaves us with is a > bit of hope that attempts will be made to stay backward compatible in the > new 2.0 release. What about the "conceptual approach", how many things can > we expect to be different, new or completely dissapear (multiproject, > repository, ...goals)? > > Could someone point me to a document/person that can give a bit more of > vision/explanation concerning these issues? What would you suggest to a > project that is just about to jump into maven? > > Thanks. > > -Sejo > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
