Re: RE : [ANN] Continuum 1.0 Alpha 4 Released
I don't test empty password with ths url scm:cvs:pserver:anoncvs:@ip:/local/cvs/Repository:module Can you try it? If it doesn't work, you should run cvs login on your machine for this cvsroot Emmanuel Olivier Lamy wrote: Hi all, I have a trouble with the cvs password which is apparently needed ?? I have a scm url : scm:cvs:pserver:[EMAIL PROTECTED]:/local/cvs/Repository:module. The password associated to anoncvs is an empty password. The output generated is : Exception:Cannot checkout sources.Exception while executing SCM command.password is required This configuration worked with alpha-3. Do I need to configure empty password somewhere ? Thanks, Olivier -Message d'origine- De : Emmanuel Venisse [mailto:[EMAIL PROTECTED] Envoyé : mardi 20 septembre 2005 16:57 À : dev@maven.apache.org; users@maven.apache.org; continuum-users@maven.apache.org; announce@apache.org Objet : [ANN] Continuum 1.0 Alpha 4 Released The Maven team is pleased to announce the 1.0-alpha-4 release of Continuum. This release offers users both an advance look at what's in Continuum 1.0 and a head start in helping to shape the final Continuum release. You can find everything here: http://maven.apache.org/continuum The binaries can be found here: http://maven.apache.org/continuum/download.html Among the improvements, we have now: - Schedule support, each project can use its own schedule - Build definitions, each project can run multiple build whith different options/goals/profiles - Added a jabber notifier - Added a msn notifier The change log can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleN ame=Htmlversion=11665 styleName=Htmlversion=11665 Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. -- Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. -
Re: versioned jars and InstallShield
And in Maven 1.x ? 2005/9/20, Edwin Punzalan [EMAIL PROTECTED]: If you don't want to use the default artifact naming convention used by m2, you can set the filename of the package in your pom.xml like so: project ... build finalNamename/finalName /build ... /project with the above set, the output file will be: name.jar (or name.war, whatever the pom packaging is). ^_^ Wim Deblauwe wrote: Hi, is there anybody that uses Maven and InstallShield? We have a problem using both together when we think about updates. InstallShield can only update a file if it keeps the same name, but since Maven puts the version in the name, we have a problem there. Has anybody solved this problem in some way that is easy to maintain? Or can InstallShield handle this but is our installer guy unaware of this? regards, Wim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: clean plugin
jan_bar wrote on Monday, September 19, 2005 6:27 PM: Thanks Jörg, it was published in http://article.gmane.org/gmane.comp.jakarta.turbine.maven.user/19338. The solution replaces the multiproject:clean goal completely (the plugin should use this impl). What is the purpose of the postGoal? By current release you mean maven 1.1 beta2 or maven 2 beta 1? The postGoal ensures, that not only the target directories of the subproject are deleted, but also the one of the base project. This has been fixed in the multiproject plugin, but I am not sure in which version (therefore current, it's not in the version installed with M102). - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mails from gmane gateway marked as (possible) spam
Hi, I want to contact administrator of this list. I post through gmane gateway and my mail are marked as spam: X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=FORGED_YAHOO_RCVD,PRIORITY_NO_NAME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Can someone look into this issue? Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mails from gmane gateway marked as (possible) spam
umm, it says Spam-Status: No, and your mails get through. Please direct any further questions to [EMAIL PROTECTED] - Brett On 9/20/05, jan_bar [EMAIL PROTECTED] wrote: Hi, I want to contact administrator of this list. I post through gmane gateway and my mail are marked as spam: X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=FORGED_YAHOO_RCVD,PRIORITY_NO_NAME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org http://apache.org Can someone look into this issue? Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Extending Eclipse plugin
Hi, I have a use case where I need to reuse/extend the functionality provided by existing M2 Eclipse plugin. The use case involves creating deployables directory from defined project properties and some other updates to .wtpmodules contents. What I want to do is to create sort of a wrapper plugin that can delegate 'standard' goals to the Eclipse plugin and do some pre/post processing around these 'standard' goals. Could anyone please explain what would be a neat way to achieve this and keep the option of being able to reuse future Eclipse plugin releases but just updating the version numbers in pom. Thanks in advance for all the help. Cheers, Rahul
Fw :[m2-beta-1] Ear plugin: root-context copied JARs/WARs
Nobody has an answer for these 2 little questions? For the second question, I've struggled with scopes, but it seems that because of the transitive dependencies feature, the Ear plugin packages every Jar set to compile/runtime in the pom of the War... Fabrice. - Hi guys! I've 2 little questions about the Ear plugin (version 2.0beta1): 1- how can I tell the Ear plugin to use a specific root-context for a War when it generates the application.xml? (instead of using the artifactId) Something like the ear.appxml.war.context-root in m1. 2- when the plugin generates the Ear, it packages most dependencies of the War module, while they already exist the the WEB-INF/lib of the War (and I don't want them to be copied a second time at the root of the Ear). Those dependencies have a compile scope in the pom of the War module. Is it the normal behaviour? Is there a property or something to tell m2 not to package them? Thanks for your help! Cheers, Fabrice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] finalName in install and version for different environments
I have a project to build / deploy for three different enviroments (test,integration, production with different configs) and want to set the jar file name depending on the active profile. I know one possibility is with the finalName Element. The jar process uses the finalName and generate the jar with the correct name (specified by finalName) But the install process doesn't use the finalName. How can I achieve it that the install process (and of course the deploy process) also uses the finalName. Please help! TIA Martin Kuhn ++ Diese Nachricht ist vertraulich und ausschließlich für den/die Adressaten bestimmt. Sollten Sie nicht der beabsichtigte Adressat, einer seiner Mitarbeiter oder sein Empfangsbevollmächtigter sein, ist jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser Nachricht unzulässig. In diesem Fall bitten wir, den Absender umgehend zu benachrichtigen und die Nachricht zu vernichten. Elektronisch versandte Nachrichten können durch Unberechtigte manipuliert und/oder gelesen werden, weshalb jegliche Haftung hierfür ausgeschlossen wird. ++ This communication is confidential and is intended solely for the addressee(s). If you are not the intended recipient(s), his/her assistant, or authorized recipient, any form of disclosure, reproduction, distribution or any use of this communication or the information in it, is strictly prohibited and may be unlawful. In this case, please notify the sender immediately and destroy the e-mail. Electronic communication via the Internet by e-mail may be manipulated and/or read by third parties, thus we exclude any liability whatsoever for this e-mail. ++
Error in m2 eclipse plugin
This is an issue that was pointed out on this mailinglist in 2003 on maven 1.0 and eclipse: When I run maven eclipse, it generates the .classpath file with the following entry: classpathentry kind=var rootpath=JRE_SRCROOT path=JRE_LIB sourcepath=JRE_SRC/ whereas when I create a project in Eclipse, a reference to JRE_LIB is written as: classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ With the former setting, your classpath only includes rt.jar, and nothing else. As a result, you may fail to import some classes like javax.net.*, which sits in a different jar file. This seems to be sorted out in maven 1. However, m2 eclipse:eclipse has the same problem today. I must edit the .classpath file manually after generation - but this is of course overwritten whenever dependencies change and is not a tenable option. Running m2-beta1. Oddmar Sandvik * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
m2 - cannot find jta in global repository
I get the following error in my build. Any suggestions? I see that the pom is there, but the jar is not. Downloading: http://repo1.maven.org/maven2/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Oddmar Sandvik * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 - cannot find jta in global repository
Hi there, I think jta is a sun jar. you must manually download it and install it to your local repo. You can see the url inside the pom. Regards, -allan [EMAIL PROTECTED] wrote: I get the following error in my build. Any suggestions? I see that the pom is there, but the jar is not. Downloading: http://repo1.maven.org/maven2/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Oddmar Sandvik * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - 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: m2 - cannot find jta in global repository
On 20.09.2005, at 10:54, Allan Ramirez wrote: Hi there, I think jta is a sun jar. you must manually download it and install it to your local repo. You can see the url inside the pom. Or you could use geronimo-spec.geronimo-spec-jta as a replacement. If jta is a transitive dependency, the following should work: dependency groupIdorg.hibernate/groupId artifactIdhibernate/artifactId version3.0.5/version exclusions exclusion groupIdjavax.transaction/groupId artifactIdjta/artifactId /exclusion /exclusions /dependency dependency groupIdgeronimo-spec/groupId artifactIdgeronimo-spec-jta/artifactId version1.0.1B-rc3/version /dependency Cheers, -Ralph. [EMAIL PROTECTED] wrote: I get the following error in my build. Any suggestions? I see that the pom is there, but the jar is not. Downloading: http://repo1.maven.org/maven2/javax/transaction/jta/ 1.0.1B/jta-1.0.1B.jar [WARNING] Unable to get resource from repository central (http:// repo1.maven.org/maven2) Oddmar Sandvik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SV: m2 - cannot find jta in global repository
Thanks Ralph, I think that is the key here, since it was Hibernate that generated this dependency as you rightly guessed. Cheers, - Oddmar -Opprinnelig melding- Fra: Ralph Pöllath [mailto:[EMAIL PROTECTED] Sendt: 20. september 2005 11:06 Til: Maven Users List Emne: Re: m2 - cannot find jta in global repository On 20.09.2005, at 10:54, Allan Ramirez wrote: Hi there, I think jta is a sun jar. you must manually download it and install it to your local repo. You can see the url inside the pom. Or you could use geronimo-spec.geronimo-spec-jta as a replacement. If jta is a transitive dependency, the following should work: dependency groupIdorg.hibernate/groupId artifactIdhibernate/artifactId version3.0.5/version exclusions exclusion groupIdjavax.transaction/groupId artifactIdjta/artifactId /exclusion /exclusions /dependency dependency groupIdgeronimo-spec/groupId artifactIdgeronimo-spec-jta/artifactId version1.0.1B-rc3/version /dependency Cheers, -Ralph. [EMAIL PROTECTED] wrote: I get the following error in my build. Any suggestions? I see that the pom is there, but the jar is not. Downloading: http://repo1.maven.org/maven2/javax/transaction/jta/ 1.0.1B/jta-1.0.1B.jar [WARNING] Unable to get resource from repository central (http:// repo1.maven.org/maven2) Oddmar Sandvik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 - cannot find jta in global repository
On 20.09.2005, at 11:15, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thanks Ralph, I think that is the key here, since it was Hibernate that generated this dependency as you rightly guessed. Glad I could help. With Hibernate, the same works for javax.transaction.jta and geronimo-spec.geronimo-spec-j2ee-jacc. Cheers, -Ralph. -Opprinnelig melding- Fra: Ralph Pöllath [mailto:[EMAIL PROTECTED] Sendt: 20. september 2005 11:06 Til: Maven Users List Emne: Re: m2 - cannot find jta in global repository On 20.09.2005, at 10:54, Allan Ramirez wrote: Hi there, I think jta is a sun jar. you must manually download it and install it to your local repo. You can see the url inside the pom. Or you could use geronimo-spec.geronimo-spec-jta as a replacement. If jta is a transitive dependency, the following should work: dependency groupIdorg.hibernate/groupId artifactIdhibernate/artifactId version3.0.5/version exclusions exclusion groupIdjavax.transaction/groupId artifactIdjta/artifactId /exclusion /exclusions /dependency dependency groupIdgeronimo-spec/groupId artifactIdgeronimo-spec-jta/artifactId version1.0.1B-rc3/version /dependency Cheers, -Ralph. [EMAIL PROTECTED] wrote: I get the following error in my build. Any suggestions? I see that the pom is there, but the jar is not. Downloading: http://repo1.maven.org/maven2/javax/transaction/jta/ 1.0.1B/jta-1.0.1B.jar [WARNING] Unable to get resource from repository central (http:// repo1.maven.org/maven2) Oddmar Sandvik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m1.1-b2] an empty string is not an empty string jelly bug
Try the following line in jelly:
echo0${res.targetPath}0 0${res.targetPath == ''}0/echo
My output was:
[echo] 00 0false0
So the string is empty but still it's not equal to empty.
Must be a null != empty bug, but is this possible in Jelly?
It wasn't before, because it breaks backwards compability with maven 1.0.2:
For example (partly taken from the idea plugin, which doesn't work
properly in m1.1-b2):
j:forEach var=res items=${pom.build.resources}
echo0${res.targetPath}0 0${res.targetPath == ''}0/echo
j:if test=${res.includes.isEmpty() and res.targetPath == ''}
echoNormally the resources would be have been added here/echo
...
/j:if
/j:forEach
--
With kind regards,
Geoffrey De Smet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1.1-b2] an empty string is not an empty string jelly bug
Although the bug still exists, adding targetPath solved my problem with
the idea plugin btw:
resource
directory${basedir}/src/resources/directory
targetPath/targetPath!-- It should be '' instead
of null (default) for the idea 1.6 plugin --
/resource
Geoffrey wrote:
Try the following line in jelly:
echo0${res.targetPath}0 0${res.targetPath == ''}0/echo
My output was:
[echo] 00 0false0
So the string is empty but still it's not equal to empty.
Must be a null != empty bug, but is this possible in Jelly?
It wasn't before, because it breaks backwards compability with maven 1.0.2:
For example (partly taken from the idea plugin, which doesn't work
properly in m1.1-b2):
j:forEach var=res items=${pom.build.resources}
echo0${res.targetPath}0 0${res.targetPath == ''}0/echo
j:if test=${res.includes.isEmpty() and res.targetPath == ''}
echoNormally the resources would be have been added here/echo
...
/j:if
/j:forEach
--
With kind regards,
Geoffrey De Smet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] assembly plugin
Does anyone know how to use assembly:assembly, in particular what the descriptor is supposed to be? I did hardcode it as a path to my pom from within my pom (that seems wrong) which made the plugin run without errors, but I didn't see any output file. Thanks -AW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependancy on other source project without use modules
On Sep 19, 2005, at 10:23 PM, Miks Rozenbergs wrote: Kristian Nordal kristian.nordal at gmail.com writes: You need some way of connecting them together. If you don't have a parent project, then they are just three independent projects. Then you must put the dependencies in the repository manually. You should look into creating a parent POM, modules are easy to use (and not a lot of work) and things like dependency management is very nice. Exactly -- connect them together. And IMHO defining dependancy from my.app.runtime to my.app.utils is getting pretty close to connecting two individuals together. But where should it look for the other projects? Maven doesn't know that you have that project in another directory, next to the other project. If these artifacts are not in the same project, then the only connection is through the repository. So the dependency needs to be built in advance and put into the repository. Maybe it's possible to trigger a build in some way (this would then be from the repository or something like that, when a request is done), but I haven't heard of it. So, creation of a parent project is duplication of information. I'm not sure of the inner workings of modules, but I would guess that it looks for these modules/projects in the sub-directories, not in the repository. So this is another kind of connection. This is not duplication of information, you are specifying where the project is located, not the built artifact. And what if my.app.utils depends on something else? Then someone should manually traverse all the dependancies and come up with a complete list of modules to include in parent project. I think you are mixing modules and dependencies. A dependency is fetched from the repository but modules are for defining recursive behavior in maven and relate projects (My understanding of it). Using modules, also implies (I think) defining the parent in the children POMs. This will enable Maven to generate a graph of this multi- project, so it's possible to trigger builds on dependencies in the project (since maven sees that they are connected / in the same multi- project, and know where to find the project). These are just my impressions of how things work, so some of it (or all of it) might be wrong =) -- Regards, Kristian Regards, Miks - 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: ejb and war plugins (maven 1.1 beta2)
No answers so far, but this seems to be basic question for J2EE development
with maven. Maybe I was not clear enough.
The client code generated for EJB must be included in WAR file. I don't know
how to do this with maven 1.1 beta 2 because war plugin copies only type=jar
dependencies and EJB client code is type=ejb. Is this bug or I got something
wrong?
Jan
jan_bar [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi,
ejb plugin places the EJB client code in repository in ejbs/my
client.jar.
However the war plugin uses only type=jar dependencies:
(maven-war-plugin-1.6.1/plugin.jelly, line 149)
j:if test=${dep.type =='jar'}
ant:copy todir=${webapp.build.lib} file=${lib.path}/
/j:if
Seems like bug. How can I add my EJB client jar to WAR?
Thanks, Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ejb and war plugins (maven 1.1 beta2)
I never used it but it seems to be a missing feature in the war plugin.
Can you open an issue. We'll fix it ASAP.
The behavior of the ejb plugin was certainly changed recently and the war
plugin wasn't updated.
We should add the support for types : ejb and ejb-client (generated if
maven.ejb.client.generate=true) in the war plugin.
WDYT ?
Arnaud
On 9/20/05, jan_bar [EMAIL PROTECTED] wrote:
No answers so far, but this seems to be basic question for J2EE
development
with maven. Maybe I was not clear enough.
The client code generated for EJB must be included in WAR file. I don't
know
how to do this with maven 1.1 beta 2 because war plugin copies only
type=jar
dependencies and EJB client code is type=ejb. Is this bug or I got
something
wrong?
Jan
jan_bar [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi,
ejb plugin places the EJB client code in repository in ejbs/my
client.jar.
However the war plugin uses only type=jar dependencies:
(maven-war-plugin-1.6.1/plugin.jelly, line 149)
j:if test=${dep.type =='jar'}
ant:copy todir=${webapp.build.lib} file=${lib.path}/
/j:if
Seems like bug. How can I add my EJB client jar to WAR?
Thanks, Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ejb and war plugins (maven 1.1 beta2)
http://jira.codehaus.org/browse/MPWAR-50.
I am starting with maven and j2ee, so my opinion may be of small value. For
now I added:
j:if test=${dep.type =='ejb'}
ant:copy todir=${webapp.build.lib} file=${lib.path}/
/j:if
Thanks, Jan
PS: Can I create dependency on plugin patch? Or at least check if the plugin
is of certain version and issue bug during build? The problem is that the
dependency is silently skipped.
Arnaud HERITIER [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I never used it but it seems to be a missing feature in the war plugin.
Can you open an issue. We'll fix it ASAP.
The behavior of the ejb plugin was certainly changed recently and the war
plugin wasn't updated.
We should add the support for types : ejb and ejb-client (generated if
maven.ejb.client.generate=true) in the war plugin.
WDYT ?
Arnaud
On 9/20/05, jan_bar [EMAIL PROTECTED] wrote:
No answers so far, but this seems to be basic question for J2EE
development
with maven. Maybe I was not clear enough.
The client code generated for EJB must be included in WAR file. I don't
know
how to do this with maven 1.1 beta 2 because war plugin copies only
type=jar
dependencies and EJB client code is type=ejb. Is this bug or I got
something
wrong?
Jan
jan_bar [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi,
ejb plugin places the EJB client code in repository in ejbs/my
client.jar.
However the war plugin uses only type=jar dependencies:
(maven-war-plugin-1.6.1/plugin.jelly, line 149)
j:if test=${dep.type =='jar'}
ant:copy todir=${webapp.build.lib} file=${lib.path}/
/j:if
Seems like bug. How can I add my EJB client jar to WAR?
Thanks, Jan
-
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: [m2] Extending Eclipse plugin
On Tue, 20 Sep 2005, Rinku wrote: Hi, I have a use case where I need to reuse/extend the functionality provided by existing M2 Eclipse plugin. The use case involves creating deployables directory from defined project properties and some other updates to .wtpmodules contents. What I want to do is to create sort of a wrapper plugin that can delegate 'standard' goals to the Eclipse plugin and do some pre/post processing around these 'standard' goals. Could anyone please explain what would be a neat way to achieve this and keep the option of being able to reuse future Eclipse plugin releases but just updating the version numbers in pom. I think it would be better if your changes are put in the eclipse plugin (at least for the contents of the .wtpmodules). Creation of custom directories on the other hand is not something the eclipse plugin should do - the maven build should create those too as it needs it.. maybe just use a target/... directory for that and let eclipse automatically create it, like target/classes? What are the exact changes? Do you think they are general enough to be added to the eclipse plugin? -- Kenney Thanks in advance for all the help. Cheers, Rahul -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
additional xml-files in WEB-INF directory
Hi, I am quite new to the maven:war plugin. I set up the directories as suggested (i.e. main/src/webapp) and added a WEB-INF Directory in the webapp directory since I need to add some additional xml files (struts-config.xml). Unfortunately when I run maven war the war file generated includes my WEB-INF Directory under the WEB-INF/classes directory. How can I change this behaviour? Thanks, Filip
additional xml-files in WEB-INF directory
Hi all, I am quite new to the maven war plugin. I have the following problem: I set up the following directory strutcture: Main / src / webapp Main / src / webapp / WEB-INF Main / src / java Main / src / resources I want to include some additional xml-files in my WEB-INF directory. Unfortunately using the above structure and running maven war produces a war file where my WEB-INF directory is placed in the WEB-INF/classes directory. How can I change this behaviour and where in the above structure do I put my jsp's? Thanks Filip
Sorry for the double posting (n.T.)
Re: [m2] assembly plugin
Hi. Ashley Williams wrote: Does anyone know how to use assembly:assembly, in particular what the descriptor is supposed to be? I did hardcode it as a path to my pom from within my pom (that seems wrong) which made the plugin run without errors, but I didn't see any output file. As far as I could examine the source of the assembly plugin, the descriptor is a xml file that contains a description of what to asseble. The descriptor property is a path to such a file and descriptorId is the id of a descriptor that is known to the assembly plugin. Is seems the assembly descriptors currently provided by the assembly plugin are there: http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-plugins/maven-assembly-plugin/src/main/resources/assemblies/ I've successfully run assembly:assembly setting descriptorId to one of the id in the provided assemblies (bin, src or jar-with-dependencies). m2 assembly:assembly -Dmaven.assembly.descriptorId=bin Regards, Daniel Schömer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Building eclipse plugins with maven, where can I find the eclipse jars?
Hi, I want to build my eclipse plugins with maven (maven1) Where can I find the eclipse jars to compile against? Or has everybody put them in an internal repository? I also got the maven-eclise-plugin-plugin but is it so that I have to maintain two lists of dependent jars; one in project.xml and one in plugin.xml? Or is that some trick which can generate one of these lists? Many thanks! /Lucas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: additional xml-files in WEB-INF directory
I use this setup successfully ./src/main/webapp/WEB-INF ./src/main/webapp/WEB-INF/web.xml ./src/main/webapp/WEB-INF/client-config.wsdd ./src/main/webapp/WEB-INF/server-config.wsdd ./src/main/webapp/index.jsp ./src/main/webapp/fingerprint.jsp ./src/main/webapp/happyaxis.jsp ./src/main/webapp/i18nLib.jsp ./src/main/webapp/index.html On 9/20/05, Filip Polsakiewicz [EMAIL PROTECTED] wrote: Hi all, I am quite new to the maven war plugin. I have the following problem: I set up the following directory strutcture: Main / src / webapp Main / src / webapp / WEB-INF Main / src / java Main / src / resources I want to include some additional xml-files in my WEB-INF directory. Unfortunately using the above structure and running maven war produces a war file where my WEB-INF directory is placed in the WEB-INF/classes directory. How can I change this behaviour and where in the above structure do I put my jsp's? Thanks Filip -- jesse mcconnell
Re: additional xml-files in WEB-INF directory
Success here also with an XML file. ~ ./src/main/webapp/WEB-INF ~ +-- web.xml ~ +-- test.xml results into : ~ ./target/artifactId-version/WEB-INF ~ +-- web.xml ~ +-- test.xml Which version of Maven are you using ? Also, you said you were using Main / src / webapp, didn't you mean src / main / webapp ? Yann --- Jesse McConnell [EMAIL PROTECTED] a écrit : I use this setup successfully ./src/main/webapp/WEB-INF ./src/main/webapp/WEB-INF/web.xml ./src/main/webapp/WEB-INF/client-config.wsdd ./src/main/webapp/WEB-INF/server-config.wsdd ./src/main/webapp/index.jsp ./src/main/webapp/fingerprint.jsp ./src/main/webapp/happyaxis.jsp ./src/main/webapp/i18nLib.jsp ./src/main/webapp/index.html On 9/20/05, Filip Polsakiewicz [EMAIL PROTECTED] wrote: Hi all, I am quite new to the maven war plugin. I have the following problem: I set up the following directory strutcture: Main / src / webapp Main / src / webapp / WEB-INF Main / src / java Main / src / resources I want to include some additional xml-files in my WEB-INF directory. Unfortunately using the above structure and running maven war produces a war file where my WEB-INF directory is placed in the WEB-INF/classes directory. How can I change this behaviour and where in the above structure do I put my jsp's? Thanks Filip -- jesse mcconnell ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: additional xml-files in WEB-INF directory
Hi, that was the mistake: my directory was main/src/webapp and the property was set to src/main/webapp Thanks Filip -Original Message- From: Yann Le Du [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 20, 2005 2:18 PM To: Maven Users List Subject: Re: additional xml-files in WEB-INF directory Success here also with an XML file. ~ ./src/main/webapp/WEB-INF ~ +-- web.xml ~ +-- test.xml results into : ~ ./target/artifactId-version/WEB-INF ~ +-- web.xml ~ +-- test.xml Which version of Maven are you using ? Also, you said you were using Main / src / webapp, didn't you mean src / main / webapp ? Yann --- Jesse McConnell [EMAIL PROTECTED] a écrit : I use this setup successfully ./src/main/webapp/WEB-INF ./src/main/webapp/WEB-INF/web.xml ./src/main/webapp/WEB-INF/client-config.wsdd ./src/main/webapp/WEB-INF/server-config.wsdd ./src/main/webapp/index.jsp ./src/main/webapp/fingerprint.jsp ./src/main/webapp/happyaxis.jsp ./src/main/webapp/i18nLib.jsp ./src/main/webapp/index.html On 9/20/05, Filip Polsakiewicz [EMAIL PROTECTED] wrote: Hi all, I am quite new to the maven war plugin. I have the following problem: I set up the following directory strutcture: Main / src / webapp Main / src / webapp / WEB-INF Main / src / java Main / src / resources I want to include some additional xml-files in my WEB-INF directory. Unfortunately using the above structure and running maven war produces a war file where my WEB-INF directory is placed in the WEB-INF/classes directory. How can I change this behaviour and where in the above structure do I put my jsp's? Thanks Filip -- jesse mcconnell ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - 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]
[m2] trouble accessing internal repository with beta1
Hi, since I upgraded to m2 beta 1, I'm having trouble accessing artifacts in my internal company-wide repository. m2 -X deploy prints ... [INFO] [deploy:deploy] [INFO] Retrieving previous build number from internal-repo and then hangs forever. I assume it's not an authentication problem, because changing the password in settings.xml fails immediately with an AuthenticationException. Any ideas? Cheers, -Ralph. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] trouble accessing internal repository with beta1
Hi, I'm also having troubles accessing artifacts from my corp repository. More exactly, I can access plain versions (e.g. 1.0.3), but not snapshots (e.g., 1.0.4-SNAPSHOT). Here's my conf, which was working well before m2b1 : [1] On my corp. repo : ~ common-framework ~ +-- maven-metadata-local.xml [2] ~ +-- 1.0.3 ~ +-- common-framework-1.0.3.jar ~ +-- common-framework-1.0.3.pom ~ +-- 1.0.4-SNAPSHOT ~ +-- common-framework-1.0.4-SNAPSHOT.jar ~ +-- common-framework-1.0.4-SNAPSHOT.pom ~ +-- maven-metadata-local.xml [3] [2] common-framework/maven-metadata-local.xml : ~ metadata ~ groupIdfr.as.common/groupId ~ artifactIdcommon-framework/artifactId ~ versioning ~ versions ~ version1.0.4-SNAPSHOT/version ~ version1.0.3/version ~ /versions ~ /versioning ~ /metadata [3] common-framework/maven-metadata-local.xml : ~ metadata ~ groupIdfr.as.common/groupId ~ artifactIdcommon-framework/artifactId ~ version1.0.4-SNAPSHOT/version ~ versioning ~ snapshot ~ localCopytrue/localCopy ~ /snapshot ~ /versioning ~ /metadata [4] In my local settings.xml : ~ mirrors ~ mirror ~ mirrorOfcentral/mirrorOf ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ /mirror ~ mirror ~ mirrorOfcentral-plugins/mirrorOf ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ /mirror ~ mirror ~ mirrorOfcentral-plugins-snapshots/mirrorOf ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ /mirror ~ /mirrors ... ~ profiles ~ profile ~ repositories ~ repository ~ idcentral/id ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ snapshotPolicyalways/snapshotPolicy ~ /repository ~ /repositories ~ pluginRepositories ~ pluginRepository ~ idcentral-plugins/id ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ snapshotPolicyalways/snapshotPolicy ~ /pluginRepository ~ pluginRepository ~ idcentral-plugins-snapshots/id ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ snapshotPolicyalways/snapshotPolicy ~ /pluginRepository ~ /pluginRepositories ~ /profile ~ /profiles Yann --- Ralph Pöllath [EMAIL PROTECTED] a écrit : Hi, since I upgraded to m2 beta 1, I'm having trouble accessing artifacts in my internal company-wide repository. m2 -X deploy prints ... [INFO] [deploy:deploy] [INFO] Retrieving previous build number from internal-repo and then hangs forever. I assume it's not an authentication problem, because changing the password in settings.xml fails immediately with an AuthenticationException. Any ideas? Cheers, -Ralph. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yahoo! Mail - Votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://mail.yahoo.fr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1.1b1] log4j error
Is this solved in Maven 1.1 beta 2? Also what is the JIRA issue related to this problem? 2005/8/25, Arnaud HERITIER [EMAIL PROTECTED]: you can safely ignore them we'll try to remove them as soon as possible. an issue is open in velocity Arnaud On 8/25/05, Wim Deblauwe [EMAIL PROTECTED] wrote: And is there a fix for it or can I safely ignore those errors? 2005/8/25, Arnaud HERITIER [EMAIL PROTECTED]: This is a problem between velocity 1.4 and log4J. Arnaud On 8/25/05, Wim Deblauwe [EMAIL PROTECTED] wrote: Hi, I get the following error in my build since I upgraded to Maven 1.1beta1 . Any idea what might be the problem? log4j:ERROR Attempted to append to closed appender named [null]. I get that same line many, many times but the build seems to continue fine. regards, Wim
Re: ejb and war plugins (maven 1.1 beta2)
On 9/20/05, jan_bar [EMAIL PROTECTED] wrote:
http://jira.codehaus.org/browse/MPWAR-50.
I am starting with maven and j2ee, so my opinion may be of small value.
For
now I added:
j:if test=${dep.type =='ejb'}
ant:copy todir=${webapp.build.lib} file=${lib.path}/
/j:if
It's good.
Thanks, Jan
PS: Can I create dependency on plugin patch? Or at least check if the
plugin
is of certain version and issue bug during build? The problem is that the
dependency is silently skipped.
You can create a dependency on your project to use a GIVEN version of a
plugin.
!-- Maven STAT CVS Plugin --
dependency
groupIdstatcvs/groupId
artifactIdmaven-statcvs-plugin/artifactId
version2.7/version
typeplugin/type
urlhttp://statcvs-xml.berlios.de/maven-plugin//url
/dependency
We also created a new tag to check if a minimal version of a plugin is
available but it will not help you because :
- it's in the plugin-plugin which isn't yet released
- it will move your problem because your build will fail if you dont have
at least this new version of the plugin-plugin.
A workaround is to copy the code in your maven.xml :
http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/plugin/plugin.jelly
definition, search for :
define:tag name=assertPluginAvailable
usage :
assert:assertPluginAvailable groupId=maven
artifactId=maven-artifact-plugin minRelease=1.3
neededBy=${plugin.artifactId}/
Arnaud
Arnaud
Arnaud HERITIER [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I never used it but it seems to be a missing feature in the war plugin.
Can you open an issue. We'll fix it ASAP.
The behavior of the ejb plugin was certainly changed recently and the war
plugin wasn't updated.
We should add the support for types : ejb and ejb-client (generated if
maven.ejb.client.generate=true) in the war plugin.
WDYT ?
Arnaud
On 9/20/05, jan_bar [EMAIL PROTECTED] wrote:
No answers so far, but this seems to be basic question for J2EE
development
with maven. Maybe I was not clear enough.
The client code generated for EJB must be included in WAR file. I don't
know
how to do this with maven 1.1 beta 2 because war plugin copies only
type=jar
dependencies and EJB client code is type=ejb. Is this bug or I got
something
wrong?
Jan
jan_bar [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi,
ejb plugin places the EJB client code in repository in ejbs/my
client.jar.
However the war plugin uses only type=jar dependencies:
(maven-war-plugin-1.6.1/plugin.jelly, line 149)
j:if test=${dep.type =='jar'}
ant:copy todir=${webapp.build.lib} file=${lib.path}/
/j:if
Seems like bug. How can I add my EJB client jar to WAR?
Thanks, Jan
-
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: [m2] trouble accessing internal repository with beta1
Erratum : the [3] sample is common-framework/1.0.4-SNAPSHOT/maven-metadata-local.xml, of course. --- Yann Le Du [EMAIL PROTECTED] a écrit : Hi, I'm also having troubles accessing artifacts from my corp repository. More exactly, I can access plain versions (e.g. 1.0.3), but not snapshots (e.g., 1.0.4-SNAPSHOT). Here's my conf, which was working well before m2b1 : [1] On my corp. repo : ~ common-framework ~ +-- maven-metadata-local.xml [2] ~ +-- 1.0.3 ~ +-- common-framework-1.0.3.jar ~ +-- common-framework-1.0.3.pom ~ +-- 1.0.4-SNAPSHOT ~ +-- common-framework-1.0.4-SNAPSHOT.jar ~ +-- common-framework-1.0.4-SNAPSHOT.pom ~ +-- maven-metadata-local.xml [3] [2] common-framework/maven-metadata-local.xml : ~ metadata ~ groupIdfr.as.common/groupId ~ artifactIdcommon-framework/artifactId ~ versioning ~ versions ~ version1.0.4-SNAPSHOT/version ~ version1.0.3/version ~ /versions ~ /versioning ~ /metadata [3] common-framework/maven-metadata-local.xml : ~ metadata ~ groupIdfr.as.common/groupId ~ artifactIdcommon-framework/artifactId ~ version1.0.4-SNAPSHOT/version ~ versioning ~ snapshot ~ localCopytrue/localCopy ~ /snapshot ~ /versioning ~ /metadata [4] In my local settings.xml : ~ mirrors ~ mirror ~ mirrorOfcentral/mirrorOf ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ /mirror ~ mirror ~ mirrorOfcentral-plugins/mirrorOf ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ /mirror ~ mirror ~ mirrorOfcentral-plugins-snapshots/mirrorOf ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ /mirror ~ /mirrors ... ~ profiles ~ profile ~ repositories ~ repository ~ idcentral/id ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ snapshotPolicyalways/snapshotPolicy ~ /repository ~ /repositories ~ pluginRepositories ~ pluginRepository ~ idcentral-plugins/id ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ snapshotPolicyalways/snapshotPolicy ~ /pluginRepository ~ pluginRepository ~ idcentral-plugins-snapshots/id ~ urlhttp://ricfiled.as.asd.asf/maven/repository/url ~ snapshotPolicyalways/snapshotPolicy ~ /pluginRepository ~ /pluginRepositories ~ /profile ~ /profiles Yann --- Ralph Pöllath [EMAIL PROTECTED] a écrit : Hi, since I upgraded to m2 beta 1, I'm having trouble accessing artifacts in my internal company-wide repository. m2 -X deploy prints ... [INFO] [deploy:deploy] [INFO] Retrieving previous build number from internal-repo and then hangs forever. I assume it's not an authentication problem, because changing the password in settings.xml fails immediately with an AuthenticationException. Any ideas? Cheers, -Ralph. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yahoo! Mail - Votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://mail.yahoo.fr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1.1b1] log4j error
Not it's not yet resolved :-( I'll take a look at it. I'm not sure that an issue was opened. Arnaud On 9/20/05, Wim Deblauwe [EMAIL PROTECTED] wrote: Is this solved in Maven 1.1 beta 2? Also what is the JIRA issue related to this problem? 2005/8/25, Arnaud HERITIER [EMAIL PROTECTED]: you can safely ignore them we'll try to remove them as soon as possible. an issue is open in velocity Arnaud On 8/25/05, Wim Deblauwe [EMAIL PROTECTED] wrote: And is there a fix for it or can I safely ignore those errors? 2005/8/25, Arnaud HERITIER [EMAIL PROTECTED]: This is a problem between velocity 1.4 and log4J. Arnaud On 8/25/05, Wim Deblauwe [EMAIL PROTECTED] wrote: Hi, I get the following error in my build since I upgraded to Maven 1.1beta1 . Any idea what might be the problem? log4j:ERROR Attempted to append to closed appender named [null]. I get that same line many, many times but the build seems to continue fine. regards, Wim
Re: SPAM: Problem with authenticated POM URLs
Hi Emmanuel, I found the problem deep within plexus, see: http://jira.codehaus.org/browse/PLX-157 Do you think this will get in for alpha4? Cheers, Mark On 20/09/05, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi Mark, authorized urls are http[s]://[username:[EMAIL PROTECTED]/urel/to/pom.xml I think your url was incorrect because continuum couldn't download it (The URL you provided doesn't exist). Try to obtain the correct url in your browser and then put it in continuum. Do you have a particular authentication mode on your server? If it doesn't work, you can upload your pom. Emmanuel Mark Hobson wrote: Hi there, I'm having problems with authenticated POM URLs with the build continuum-20050920.033000.tar.gz. Our SVN repository is accessible via authenticated https and authenticated http internally, so I've been trying the following and get the corresponding errors: https://my.domain/url/to/pom.xml The URL you provided doesn't exist https://[EMAIL PROTECTED]/url/to/pom.xml You must provide a valid url https://username:[EMAIL PROTECTED]/url/to/pom.xml The URL you provided doesn't exist http://my.domain/url/to/pom.xml The URL you provided doesn't exist http://[EMAIL PROTECTED]/url/to/pom.xml You must provide a valid url http://username:[EMAIL PROTECTED]/url/to/pom.xml The URL you provided doesn't exist There are no errors in the logs (aside from the side-issue of: WARN VelocityComponent - org.apache.velocity.runtime.exception.ReferenceException: reference : template = screens/AddMavenProject.vm [line 1,column 16] : $fvr.getElementResult( $element.getId() ).errorMessage is not a valid reference. which causes [ $fvr.getElementResult( $element.getId() ).errorMessage ] to be displayed as the validation message alongside the upload POM field). I see from CONTINUUM-306 that https should be supported - am I doing anything wrong? Cheers, Mark
[m2] reasons for sticking with maven
Sincere apologies to the dev team if this email seems like a troll, I absolutely don't mean it to be. I'm aware that they continue to do outstanding work and are few in number. The more I use Maven the more I get a feel for the size and shape of it and find myself looking for features that aren't there. Since I joined the community I've posted questions on what I consider to be the most important aspects of a build system namely (yes in this order): 1. Usability from Ant - there are hundreds of Ant targets out there that are useful for me today. I can't justify waiting for them to be rewritten as Maven equivalents not only because I need functionality today, but also because I don't see why I have to abandon my experience with ant. 2. Usability from Eclipse - when will I be able to ditch the command line and create and manage projects entirely from eclipse 3. Need to do a myriad of simple things such as automatically run java command or deploy to tomcat. I used to do this all the time in my ant scripts, ie run my build.xml script and at the end it would run my app on completion. It's a credit to those on this list who reply with ideas and workarounds - however this is kind of related to 2 above, where there are lots of ant tasks out there that are tested to death and that I should be able to use today. 4. Online documentation. Simple example was trying to get the assembly plugin to work which Daniel Shomer had to look into the source code to advise me of what to do. This is just one example of many. 5. Other project structures. Sometimes I will encounter a project where all the source code is in one tree (beginning with com/). I'm not saying its any better than one directory per artifact, but I am saying I encounter such projects in my career and as such I know I wouldn't be able to use maven. 6. Contribute to the code. I have tried to get a foot in the door in order to fix some of my own critisisms, but the lack of javadocs mean that I really can't do this other than for some simple plugins. That is unless I had lots of time to spare which I don't. In turn that makes me concerned how the project will attract other developers to move things along quickly. I realize there may be workarounds for some of the above, but I couldn't stick my neck on the line for a dev team and recommend sharing of eclipse hack scripts etc as a way of working. I'm also putting my selfish hat on and say that I'd like to do the above without defending it - there are a few threads on this list already that deal with the pros and cons. *** Now I'll turn my attention to Ivy. I've began to look at this product and it seems to offer many of the features of Maven including 1. transitive dependencies 2. compatibility with the ibiblio repository and in addition 1. the online docs are excellent even if they are in broken english 2. Can manage projects from with eclipse, since they are just ant projects (with simple projects, haven't tried anything tricky) 3. Can manage maven style module directory structures or single source trees. Obviously being Ant, it can manage any structure you like, but these are the only two sane ones I know. Yes there is stuff that it doesn't have such as a built in lifecycle, but with what I've learnt from the maven layout, I feel I could quite easily replicate that in ant in a reusable way. That said I would prefer not to have to. I suppose I'm looking for reassurance as to why Maven is the way to go because there seems to be considerable overlap with Ivy. I realize that I am being very selfish here, but I have to think very carefully about what I invest my time in. Maven has all the hallmarks of being that software that I felt was missing during my career, which is why I care enough about it to spare the time for these critisisms. I just want to be sure it has a chance of gaining critical mass. Maybe the gatekeeper/guardian of this project needs to write some sort of Jerry Maguire style memo that says what Maven's purpose is and plans are so that we can all keep focused on that. Maybe my views aren't representative of a large enough demographic in which case this email will just slip away into obscurity, but either way thanks for reading and please don't take it as a troll -AW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] assembly plugin
Thanks that worked although I didn't find what I was hoping for in the resulting zip file. On 20 Sep 2005, at 12:49, Daniel Schömer wrote: Hi. Ashley Williams wrote: Does anyone know how to use assembly:assembly, in particular what the descriptor is supposed to be? I did hardcode it as a path to my pom from within my pom (that seems wrong) which made the plugin run without errors, but I didn't see any output file. As far as I could examine the source of the assembly plugin, the descriptor is a xml file that contains a description of what to asseble. The descriptor property is a path to such a file and descriptorId is the id of a descriptor that is known to the assembly plugin. Is seems the assembly descriptors currently provided by the assembly plugin are there: http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven- plugins/maven-assembly-plugin/src/main/resources/assemblies/ I've successfully run assembly:assembly setting descriptorId to one of the id in the provided assemblies (bin, src or jar-with-dependencies). Regards, Daniel Schömer - 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: ejb and war plugins (maven 1.1 beta2)
I opened on Jira a release 1.6.2 So we're working on the 1.6.2-SNAPSHOT The name of the patch isn't important Arnaud On 9/20/05, jan_bar [EMAIL PROTECTED] wrote: Thanks Arnaud, one more question: If I want to create my patch, which version of the plugin should I use so it will not conflict with war plugin patch once published? WAR plugin is now 1.6.1, can I name it 1.6.1-patch? I think that there should be only number on the version, so 1.6.1.1 http://1.6.1.1 would be better? Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw :[m2-beta-1] Ear plugin: root-context copied JARs/WARs
On Tue, 20 Sep 2005 [EMAIL PROTECTED] wrote: Hi, Nobody has an answer for these 2 little questions? Sorry but I missed this one! For the second question, I've struggled with scopes, but it seems that because of the transitive dependencies feature, the Ear plugin packages every Jar set to compile/runtime in the pom of the War... See below. Fabrice. - Hi guys! I've 2 little questions about the Ear plugin (version 2.0beta1): 1- how can I tell the Ear plugin to use a specific root-context for a War when it generates the application.xml? (instead of using the artifactId) Something like the ear.appxml.war.context-root in m1. Use the plugin configuration. You can specify configuration options for the modules: modules webModule contextRoot/yourContextRoot//contextRoot urithe_web_uri/uri !-- if needed.. -- /webModule /modules Maybe Stephane Nicoll can confirm if this is correct? I personally use xdoclet and j2ee specific descriptor files within the WEB-INF directory of the war itself, because you can specify the location there too, and it'll work even if you deploy the war standalone. On the other hand, for ears, it's best to use application.xml. 2- when the plugin generates the Ear, it packages most dependencies of the War module, while they already exist the the WEB-INF/lib of the War (and I don't want them to be copied a second time at the root of the Ear). Those dependencies have a compile scope in the pom of the War module. Is it the normal behaviour? Is there a property or something to tell m2 not to package them? Well this is a bit of a problem. You can specify the dependencies in the war pom with scope 'provided', so they won't end up in the war. This works great if you always use the war within an ear that also has those dependencies, but if you use that war standalone it'll break. Also, those war dependencies are not transferred to the ear project, so you have to respecify them there. Thanks for your help! Sorry we missed this! -- Kenney Cheers, Fabrice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Continuum 1.0 Alpha 4 Released
The Maven team is pleased to announce the 1.0-alpha-4 release of Continuum. This release offers users both an advance look at what's in Continuum 1.0 and a head start in helping to shape the final Continuum release. You can find everything here: http://maven.apache.org/continuum The binaries can be found here: http://maven.apache.org/continuum/download.html Among the improvements, we have now: - Schedule support, each project can use its own schedule - Build definitions, each project can run multiple build whith different options/goals/profiles - Added a jabber notifier - Added a msn notifier The change log can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=11665 Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2-b1] POM Inheritance and Variables
Hi,
I have the following section in a parent POM:
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
debug${systemScope.getProperty('build.debug')}/debug
source${systemScope.getProperty('build.jdk')}/source
target${systemScope.getProperty('build.jdk')}/target
/configuration
/plugin
/plugins
/pluginManagement
When I run a Maven build on the child POM the system scope variables appear to
have no effect.
If I replace them with fixed values then everything works.
The system variables are set when invoking Maven using -D option.
What have I done wrong?
Does the fact that this inherited have any bearing on the property evaluation?
Many Thanks
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Comments are inline. Please bear with me, I think my responses are as lengthy as your original email! :( Cheers, John Ashley Williams wrote: | Sincere apologies to the dev team if this email seems like a troll, I | absolutely don't mean it to be. I'm aware that they continue to do | outstanding work and are few in number. | | The more I use Maven the more I get a feel for the size and shape of it | and find myself looking for features that aren't there. Since I joined | the community I've posted questions on what I consider to be the most | important aspects of a build system namely (yes in this order): | | 1. Usability from Ant - there are hundreds of Ant targets out there | that are useful for me today. I can't justify waiting for them to be | rewritten as Maven equivalents not only because I need functionality | today, but also because I don't see why I have to abandon my experience | with ant. I've already addressed this with you and others on this list. I've mentioned that I'm fully in favor of this sort of integration, and I have some starting points from Chris that I'll be putting in to allow this sort of thing. You don't have to wait for all of Ant's API to be replicated; you only have to wait for me to get this one change in place. :) | | 2. Usability from Eclipse - when will I be able to ditch the command | line and create and manage projects entirely from eclipse This depends on people with Eclipse development experience (not experience using Eclipse) picking up the task and running with it. We're trying to get something together in the way of a more concerted effort, but I'm sure you'll agree that getting a stable API was the first thing to do, since otherwise the Eclipse integration project would have to track a moving target. Now that we've got a beta-1 release, we can start thinking about this. | | 3. Need to do a myriad of simple things such as automatically run java | command or deploy to tomcat. I used to do this all the time in my ant | scripts, ie run my build.xml script and at the end it would run my app | on completion. It's a credit to those on this list who reply with ideas | and workarounds - however this is kind of related to 2 above, where | there are lots of ant tasks out there that are tested to death and that | I should be able to use today. The funny thing about Maven 2 is that it facilitates external plugin development. You can load a plugin from a repository hosted anywhere. Personally, I feel strongly that executing random commands from within the build process is a Bad Thing, and a thing that is bad and common with Ant. Maven - and also Ant, to a lesser extent - is a build tool. It's not a launching platform, and it's not a tool to be used to run your coffee maker. Executing random commands from a configuration in a POM is: a. unscaleable, since that runtime config is not encapsulated for reuse b. bound to partition your build logic into multiple pieces, which now have to be maintained from multiple sources. In Ant, you can do anything you please, including things that don't relate to the process of building software. It's important to keep a clear idea of the problem domain we're trying to address here. Having said that, there's nothing stopping you from hosting your own maven-foo-plugin on Sourceforge or somesuch. If you find what you perceive to be a hole in our plugin offering, and cannot convince us to fill it, there's nothing stopping you from scratching your own itch. We currently have maven-execute-plugin on the mojos project, but I'd really like to see it deprecated and eliminated eventually. | | 4. Online documentation. Simple example was trying to get the assembly | plugin to work which Daniel Shomer had to look into the source code to | advise me of what to do. This is just one example of many. You're not the first to point this out, and properly so. Just this week, one of the devs started fulltime on fixing this. Documentation has lagged for a few reasons, which I don't offer as excuses. First, the devs have been trying to stabilize the featureset and functionality before we try to document it. This is sort of a chicken-egg scenario, because (as was pointed out) its easier to maintain a clear design between multiple devs when you have documentation, but documentation of an evolving API gets stale quickly. Now that you've read the source code for the assembly plugin, will you contribute some documentation? | | 5. Other project structures. Sometimes I will encounter a project where | all the source code is in one tree (beginning with com/). I'm not | saying its any better than one directory per artifact, but I am saying | I encounter such projects in my career and as such I know I wouldn't be | able to use maven. This project can get a little preachy, and I'm no exception. We tend to believe that we've seen a lot of use cases (many on this list), and that our standard layout is
Re: ejb and war plugins (maven 1.1 beta2)
I published a snapshot you can install it locally maven plugin:download -Dmaven.repo.remote=http:www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven http://cvs.apache.org/repository/-DgroupId=maven-DartifactId=maven-war-plugin -Dversion= 1.6.2-SNAPSHOT or you can reference it in your project : in your project.xml : dependency groupIdmaven/groupId artifactIdmaven-war-plugin/artifactId version1.6.2-SNAPSHOT/version typeplugin/type /dependency in your project.properties: maven.repo.remote=http:www.ibiblio.org/maven, http://cvs.apache.org/repository/ Arnaud On 9/20/05, Arnaud HERITIER [EMAIL PROTECTED] wrote: I opened on Jira a release 1.6.2 So we're working on the 1.6.2-SNAPSHOT The name of the patch isn't important Arnaud On 9/20/05, jan_bar [EMAIL PROTECTED] wrote: Thanks Arnaud, one more question: If I want to create my patch, which version of the plugin should I use so it will not conflict with war plugin patch once published? WAR plugin is now 1.6.1, can I name it 1.6.1-patch ? I think that there should be only number on the version, so 1.6.1.1 http://1.6.1.1 would be better? Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2-b1] POM Inheritance and Variables
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
System vars are accessed implicitly in m2...try:
configuration
~ debug${build.debug}/debug
~ source${build.jdk}/source
~ target${build.jdk}/target
/configuration
Cheers,
john
David Pick wrote:
| Hi,
|
| I have the following section in a parent POM:
|
| pluginManagement
| plugins
| plugin
| groupIdorg.apache.maven.plugins/groupId
| artifactIdmaven-compiler-plugin/artifactId
| configuration
|
debug${systemScope.getProperty('build.debug')}/debug
|
source${systemScope.getProperty('build.jdk')}/source
|
target${systemScope.getProperty('build.jdk')}/target
| /configuration
| /plugin
| /plugins
| /pluginManagement
|
|
| When I run a Maven build on the child POM the system scope variables
appear to have no effect.
| If I replace them with fixed values then everything works.
|
| The system variables are set when invoking Maven using -D option.
|
| What have I done wrong?
|
| Does the fact that this inherited have any bearing on the property
evaluation?
|
| Many Thanks
| Dave
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMCksK3h2CZwO/4URAnjtAKCR9xO/PWerEM72jUXyapJpax04KQCfQfzR
dpkEVBR7Dwp/SaWGrB55M4w=
=L4D+
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] assembly plugin
Ashley Williams wrote: On 20 Sep 2005, at 12:49, Daniel Schömer wrote: Ashley Williams wrote: Does anyone know how to use assembly:assembly, in particular what the descriptor is supposed to be? I did hardcode it as a path to my pom from within my pom (that seems wrong) which made the plugin run without errors, but I didn't see any output file. I've successfully run assembly:assembly setting descriptorId to one of the id in the provided assemblies (bin, src or jar-with-dependencies). Thanks that worked although I didn't find what I was hoping for in the resulting zip file. Hm, I don't know what you expected in the resulting zip file, but the results I've gotten were as I've expected. The assemblies shipped with the assembly plugin are relatively simple xml files specifying file-sets of what to include. Since you know ant (as you wrote in [EMAIL PROTECTED]), you can probably adapt the assembly xml files to your needs. Regards, Daniel Schömer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2-b1] POM Inheritance and Variables
On Tue, 2005-09-20 at 16:07 +0100, David Pick wrote:
Hi,
I have the following section in a parent POM:
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
debug${systemScope.getProperty('build.debug')}/debug
source${systemScope.getProperty('build.jdk')}/source
target${systemScope.getProperty('build.jdk')}/target
/configuration
/plugin
/plugins
/pluginManagement
Using ${build.jdk} with -Dbuild.jdk=1.5 on the command line should work.
--
Trygve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2-b1] POM Inheritance and Variables
John,
Many Thanks, that did the trick.
Cheers
Dave
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: 20 September 2005 16:22
To: Maven Users List
Subject: Re: [m2-b1] POM Inheritance and Variables
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
System vars are accessed implicitly in m2...try:
configuration
~ debug${build.debug}/debug
~ source${build.jdk}/source
~ target${build.jdk}/target
/configuration
Cheers,
john
David Pick wrote:
| Hi,
|
| I have the following section in a parent POM:
|
| pluginManagement
| plugins
| plugin
| groupIdorg.apache.maven.plugins/groupId
| artifactIdmaven-compiler-plugin/artifactId
| configuration
|
debug${systemScope.getProperty('build.debug')}/debug
|
source${systemScope.getProperty('build.jdk')}/source
|
target${systemScope.getProperty('build.jdk')}/target
| /configuration
| /plugin
| /plugins
| /pluginManagement
|
|
| When I run a Maven build on the child POM the system scope variables
appear to have no effect.
| If I replace them with fixed values then everything works.
|
| The system variables are set when invoking Maven using -D option.
|
| What have I done wrong?
|
| Does the fact that this inherited have any bearing on the property
evaluation?
|
| Many Thanks
| Dave
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMCksK3h2CZwO/4URAnjtAKCR9xO/PWerEM72jUXyapJpax04KQCfQfzR
dpkEVBR7Dwp/SaWGrB55M4w=
=L4D+
-END PGP SIGNATURE-
-
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: [m2] assembly plugin + a few instructions
I was expecting the jars from my dependencies section to be there. However I did manage to find an example of a descriptor file by greping in the maven source - it's under maven-assembly-plugin/ For anyone who's interested I'm actually trying to see if there is enough in Maven to allow me to cobble together an application, including Class-path entries in manfest, and there is just about. Here's what I did: I added the following to my pom so that my manifest would be generated correctly and that the assembly plugin would find my descriptor: plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId configuration descriptorapp.xml/descriptor /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest mainClasscom.example.mbeans.Main/mainClass addClasspathtrue/addClasspath /manifest /archive /configuration /plugin /plugins then I created the following descriptor app.xml: assembly idbin/id formats formattar.gz/format formattar.bz2/format formatzip/format /formats fileSets fileSet directorytarget/directory outputDirectory/outputDirectory includes include*.jar/include /includes /fileSet /fileSets dependencySets dependencySet outputDirectory//outputDirectory scoperuntime/scope /dependencySet /dependencySets /assembly Which resulted in a compressed file(s) containing my jar file and its dependencies. I was then able to uncompress it and launch with the java -jar command. Cheers AW On 20 Sep 2005, at 16:21, Daniel Schömer wrote: Ashley Williams wrote: On 20 Sep 2005, at 12:49, Daniel Schömer wrote: Ashley Williams wrote: Does anyone know how to use assembly:assembly, in particular what the descriptor is supposed to be? I did hardcode it as a path to my pom from within my pom (that seems wrong) which made the plugin run without errors, but I didn't see any output file. I've successfully run assembly:assembly setting descriptorId to one of the id in the provided assemblies (bin, src or jar-with-dependencies). Thanks that worked although I didn't find what I was hoping for in the resulting zip file. Hm, I don't know what you expected in the resulting zip file, but the results I've gotten were as I've expected. The assemblies shipped with the assembly plugin are relatively simple xml files specifying file-sets of what to include. Since you know ant (as you wrote in [EMAIL PROTECTED]), you can probably adapt the assembly xml files to your needs. Regards, Daniel Schömer - 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: [m2] reasons for sticking with maven
On Tue, 2005-09-20 at 14:19 +0100, Ashley Williams wrote: 1. Usability from Ant - there are hundreds of Ant targets out there that are useful for me today. I can't justify waiting for them to be rewritten as Maven equivalents not only because I need functionality today, but also because I don't see why I have to abandon my experience with ant. We are rapidly trying to make Ant functionality available in m2 by creating a plugin type that allows you to script up plugins using Ant's familiar XML scripting. If you can't wait and have a pending project then your stance is understandable. For the time being you can take advantage of what we've made available via Ant tasks. 2. Usability from Eclipse - when will I be able to ditch the command line and create and manage projects entirely from eclipse This is something that is actively being pursued and something will materialize sooner rather then later. We understand the critical nature of tool integration. The importance is not lost on us, we understand. 3. Need to do a myriad of simple things such as automatically run java command or deploy to tomcat. I used to do this all the time in my ant scripts, ie run my build.xml script and at the end it would run my app on completion. It's a credit to those on this list who reply with ideas and workarounds - however this is kind of related to 2 above, where there are lots of ant tasks out there that are tested to death and that I should be able to use today. Here our aims are different. We don't want everyone scripting up everything in their own way. It may be convenient in the short term but we would prefer to wait for someone to create a coherent, consistent way to launch an appserver for testing so that it benefits all Maven users. We feel in the long run this approach serves the community better but this notion is often at odds with folks who needs to get things done Right Now(tm). 4. Online documentation. Simple example was trying to get the assembly plugin to work which Daniel Shomer had to look into the source code to advise me of what to do. This is just one example of many. The documentation is admittedly lacking. I am actually working pretty much full-time on writing doco for the release so this is not lost on us either. We know that documentation is critical for successful widespread adoption. 5. Other project structures. Sometimes I will encounter a project where all the source code is in one tree (beginning with com/). I'm not saying its any better than one directory per artifact, but I am saying I encounter such projects in my career and as such I know I wouldn't be able to use maven. That's a choice you'll have to make. Many people have found making the switch to our default ways of doing things has numerous benefits. If it's not something you can do then we understand but we feel coherency, consistency, and comprehension win out over other concerns. Make a good plugin and all Maven users benefit. Make a one off script for your own setup and you've just isolated yourself from a great source of potential help. Making a decent plugin might take you an extra 20% in time but the ultimate savings in time has shown itself in our community over and over again. We also know that new projects are starting all the time and this is the ideal time to try Maven. For people who have different structures, you will probably also find that their build now works and in these cases I would never recommend switching from Make or Ant unless you are having serious problems with maintenance. 6. Contribute to the code. I have tried to get a foot in the door in order to fix some of my own critisisms, but the lack of javadocs mean that I really can't do this other than for some simple plugins. That is unless I had lots of time to spare which I don't. In turn that makes me concerned how the project will attract other developers to move things along quickly. We have actually attracted more developers in the last 6 months then ever before. We've got 4-5 new developers on the maven project and at least as many on the Mojo project. So things are actually looking great in terms of community involvement and I think it's only going to grow as we approach a final release. There is currently a barrier to entry but we've managed to overcome that and we're working on making getting involved easier: http://maven.apache.org/maven2/developers/development-guide.html I realize there may be workarounds for some of the above, but I couldn't stick my neck on the line for a dev team and recommend sharing of eclipse hack scripts etc as a way of working. I'm also putting my selfish hat on and say that I'd like to do the above without defending it - there are a few threads on this list already that deal with the pros and cons. *** Now I'll turn my attention to Ivy. I've began to look at this product
RE: [m2] reasons for sticking with maven
John, I appreciate your thoughful and reasonable responses to
questions/issues like this. I have to second Ashley on this one. Please
try not to take the following personally, but consider it one person's
bad experience w/ trying to use m2 to do what seems like a simple
thing...
I really like being able to do m2 clean:clean compile test install.
However, I don't like having no ability to reuse test code from one
project in another project which depends on it. Example: project A has
interface Blah and interface BlahDAO to persist blahs. I have
AbstractBlahDAOTest which has testXXX methods which test *interface
invariant* conditions of BlahDAO. Project B has a new subclass of Blah
and BlahDAO, but it's ProjectBBlahDAO *must* still abide by the
interface invariant constraints. So I want to have ProjectBBlahDAOTest
which extends AbstractBlahDAOTest from project A, but I can't because I
can't generate another (test) artifact in maven.
So, I spent between 3 days and a week reading the source and the (mostly
absent) documentation for plugin development, and developed
maven-test-artfiact plugin. Finally got it to generate the
${artifactId}-test.jar AND install it, but it turns out surefire won't
run tests where some of the testXXX methods are in an abstract base
class in another jar, apparently (even though it loads the class).
To which I have to say: why the hell did someone develop surefire in the
first place? There's already a perfectly good Ant junit task? And why
their own microcontainer? What the heck was wrong w/ Spring (which lots
of people already use).
It seems to me to be a codehaus thing: a propensity to eschew reuse of
other people's code.
So, the upshot is, my plugin doesn't work. It wouldn't work outside of
m2 anyway (since m2 plugins don't rely on normal Java mechanisms -- like
setter injection, to set their properties) so it's not really general as
I've heard claimed by some here as an argument why maven plugins are
good - loosely coupled to maven. And to make it work, I might have to
hack surefire. And plexus. And whatever other 20 wheels have been
reinvented rather than reused.
I realise that some of the above may be perceived as somewhat
inflammatory, but it's really just born out of the frustration of seeing
what seems like it should be an easy task -- one which I *can't imagine*
I'm the only one requiring -- be so difficult.
And since I don't really have more time to steal from my project to
devote to the maven plugin development task, I'm left looking for
alternatives, or reluctantly planning to rewrite the build process in
Ant buildfiles in the not too distant future.
Respectfully but w/ frustration and confusion,
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ejb and war plugins (maven 1.1 beta2)
Thanks for your time Arnaud, it works for me. Vincent should fix code for http://www.onjava.com/pub/a/onjava/2005/09/07/maven.html?page=4 Jan Arnaud HERITIER [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I published a snapshot you can install it locally maven plugin:download -Dmaven.repo.remote=http:www.ibiblio.org/maven,http://cvs.apache.org/reposit ory/ -DgroupId=maven http://cvs.apache.org/repository/-DgroupId=maven-DartifactId=maven-war-plu gin -Dversion= 1.6.2-SNAPSHOT or you can reference it in your project : in your project.xml : dependency groupIdmaven/groupId artifactIdmaven-war-plugin/artifactId version1.6.2-SNAPSHOT/version typeplugin/type /dependency in your project.properties: maven.repo.remote=http:www.ibiblio.org/maven, http://cvs.apache.org/repository/ Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ejb and war plugins (maven 1.1 beta2)
He should add a requirement for the war plugin. I'll see with him.. Arnaud On 9/20/05, jan_bar [EMAIL PROTECTED] wrote: Thanks for your time Arnaud, it works for me. Vincent should fix code for http://www.onjava.com/pub/a/onjava/2005/09/07/maven.html?page=4 Jan Arnaud HERITIER [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I published a snapshot you can install it locally maven plugin:download -Dmaven.repo.remote=http:www.ibiblio.org/maven, http://cvs.apache.org/reposit ory/ -DgroupId=maven http://cvs.apache.org/repository/-DgroupId=maven -DartifactId=maven-war-plu gin -Dversion= 1.6.2-SNAPSHOT or you can reference it in your project : in your project.xml : dependency groupIdmaven/groupId artifactIdmaven-war-plugin/artifactId version1.6.2-SNAPSHOT/version typeplugin/type /dependency in your project.properties: maven.repo.remote=http:www.ibiblio.org/maven, http://cvs.apache.org/repository/ Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : [ANN] Continuum 1.0 Alpha 4 Released
Hi all, I have a trouble with the cvs password which is apparently needed ?? I have a scm url : scm:cvs:pserver:[EMAIL PROTECTED]:/local/cvs/Repository:module. The password associated to anoncvs is an empty password. The output generated is : Exception:Cannot checkout sources.Exception while executing SCM command.password is required This configuration worked with alpha-3. Do I need to configure empty password somewhere ? Thanks, Olivier -Message d'origine- De : Emmanuel Venisse [mailto:[EMAIL PROTECTED] Envoyé : mardi 20 septembre 2005 16:57 À : dev@maven.apache.org; users@maven.apache.org; continuum-users@maven.apache.org; announce@apache.org Objet : [ANN] Continuum 1.0 Alpha 4 Released The Maven team is pleased to announce the 1.0-alpha-4 release of Continuum. This release offers users both an advance look at what's in Continuum 1.0 and a head start in helping to shape the final Continuum release. You can find everything here: http://maven.apache.org/continuum The binaries can be found here: http://maven.apache.org/continuum/download.html Among the improvements, we have now: - Schedule support, each project can use its own schedule - Build definitions, each project can run multiple build whith different options/goals/profiles - Added a jabber notifier - Added a msn notifier The change log can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleN ame=Htmlversion=11665 styleName=Htmlversion=11665 Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. -- Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. -
Re: [m2] reasons for sticking with maven
On 20 Sep 2005, at 16:15, John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Comments are inline. Please bear with me, I think my responses are as lengthy as your original email! :( Cheers, John Ashley Williams wrote: | Sincere apologies to the dev team if this email seems like a troll, I | absolutely don't mean it to be. I'm aware that they continue to do | outstanding work and are few in number. | | The more I use Maven the more I get a feel for the size and shape of it | and find myself looking for features that aren't there. Since I joined | the community I've posted questions on what I consider to be the most | important aspects of a build system namely (yes in this order): | | 1. Usability from Ant - there are hundreds of Ant targets out there | that are useful for me today. I can't justify waiting for them to be | rewritten as Maven equivalents not only because I need functionality | today, but also because I don't see why I have to abandon my experience | with ant. I've already addressed this with you and others on this list. I've mentioned that I'm fully in favor of this sort of integration, and I have some starting points from Chris that I'll be putting in to allow this sort of thing. You don't have to wait for all of Ant's API to be replicated; you only have to wait for me to get this one change in place. :) I'm extremely pleased to hear this. I meet all sorts on this list and I don't know which contributors are most responsible for steering the project or are just giving there opinion on what they would like to happen. Maybe the roadmap could be maintained a little to show which suggestions have actually been taken on board. | | 2. Usability from Eclipse - when will I be able to ditch the command | line and create and manage projects entirely from eclipse This depends on people with Eclipse development experience (not experience using Eclipse) picking up the task and running with it. We're trying to get something together in the way of a more concerted effort, but I'm sure you'll agree that getting a stable API was the first thing to do, since otherwise the Eclipse integration project would have to track a moving target. Now that we've got a beta-1 release, we can start thinking about this. | | 3. Need to do a myriad of simple things such as automatically run java | command or deploy to tomcat. I used to do this all the time in my ant | scripts, ie run my build.xml script and at the end it would run my app | on completion. It's a credit to those on this list who reply with ideas | and workarounds - however this is kind of related to 2 above, where | there are lots of ant tasks out there that are tested to death and that | I should be able to use today. The funny thing about Maven 2 is that it facilitates external plugin development. You can load a plugin from a repository hosted anywhere. Personally, I feel strongly that executing random commands from within the build process is a Bad Thing, I can already do that with a mojo - I can write any old java and attach it to any old lifecycle phase. BUT I would love to get up to that same mischief using the language/syntax of Ant rather than Java! and a thing that is bad and common with Ant. Maven - and also Ant, to a lesser extent - is a build tool. It's not a launching platform, and it's not a tool to be used to run your coffee maker. Executing random commands from a configuration in a POM is: a. unscaleable, since that runtime config is not encapsulated for reuse b. bound to partition your build logic into multiple pieces, which now have to be maintained from multiple sources. In Ant, you can do anything you please, including things that don't relate to the process of building software. It's important to keep a clear idea of the problem domain we're trying to address here. Having said that, there's nothing stopping you from hosting your own maven-foo-plugin on Sourceforge or somesuch. If you find what you perceive to be a hole in our plugin offering, and cannot convince us to fill it, there's nothing stopping you from scratching your own itch. We currently have maven-execute-plugin on the mojos project, but I'd really like to see it deprecated and eliminated eventually. | | 4. Online documentation. Simple example was trying to get the assembly | plugin to work which Daniel Shomer had to look into the source code to | advise me of what to do. This is just one example of many. You're not the first to point this out, and properly so. Just this week, one of the devs started fulltime on fixing this. Documentation has lagged for a few reasons, which I don't offer as excuses. First, the devs have been trying to stabilize the featureset and functionality before we try to document it. This is sort of a chicken-egg scenario, because (as was pointed out) its easier to maintain a clear design between multiple devs when you have
Re: [m2] reasons for sticking with maven
I appreciate your response and I hope this information is useful to others as well as myself. With regards to comparing Ivy to Maven you might be right in saying it's comparing apples to oranges. Nevertheless it sure doesn't look that way to the newbie and I would say that you've made that comparison - which would interest lots of people. Maybe its worth putting it up on your website as the Ivy guys have done. http://www.jayasoft.fr/org/modules/ivy/comparison.php Maybe also a fleshed out roadmap would help with info that currently only exists on this mailing list. With both Ant and Maven out there, I believe that Maven needs more of a sales pitch to compete for eyeballs - although I realize this would be low on your list. Thanks -AW On 20 Sep 2005, at 16:49, Jason van Zyl wrote: On Tue, 2005-09-20 at 14:19 +0100, Ashley Williams wrote: 1. Usability from Ant - there are hundreds of Ant targets out there that are useful for me today. I can't justify waiting for them to be rewritten as Maven equivalents not only because I need functionality today, but also because I don't see why I have to abandon my experience with ant. We are rapidly trying to make Ant functionality available in m2 by creating a plugin type that allows you to script up plugins using Ant's familiar XML scripting. If you can't wait and have a pending project then your stance is understandable. For the time being you can take advantage of what we've made available via Ant tasks. 2. Usability from Eclipse - when will I be able to ditch the command line and create and manage projects entirely from eclipse This is something that is actively being pursued and something will materialize sooner rather then later. We understand the critical nature of tool integration. The importance is not lost on us, we understand. 3. Need to do a myriad of simple things such as automatically run java command or deploy to tomcat. I used to do this all the time in my ant scripts, ie run my build.xml script and at the end it would run my app on completion. It's a credit to those on this list who reply with ideas and workarounds - however this is kind of related to 2 above, where there are lots of ant tasks out there that are tested to death and that I should be able to use today. Here our aims are different. We don't want everyone scripting up everything in their own way. It may be convenient in the short term but we would prefer to wait for someone to create a coherent, consistent way to launch an appserver for testing so that it benefits all Maven users. We feel in the long run this approach serves the community better but this notion is often at odds with folks who needs to get things done Right Now(tm). 4. Online documentation. Simple example was trying to get the assembly plugin to work which Daniel Shomer had to look into the source code to advise me of what to do. This is just one example of many. The documentation is admittedly lacking. I am actually working pretty much full-time on writing doco for the release so this is not lost on us either. We know that documentation is critical for successful widespread adoption. 5. Other project structures. Sometimes I will encounter a project where all the source code is in one tree (beginning with com/). I'm not saying its any better than one directory per artifact, but I am saying I encounter such projects in my career and as such I know I wouldn't be able to use maven. That's a choice you'll have to make. Many people have found making the switch to our default ways of doing things has numerous benefits. If it's not something you can do then we understand but we feel coherency, consistency, and comprehension win out over other concerns. Make a good plugin and all Maven users benefit. Make a one off script for your own setup and you've just isolated yourself from a great source of potential help. Making a decent plugin might take you an extra 20% in time but the ultimate savings in time has shown itself in our community over and over again. We also know that new projects are starting all the time and this is the ideal time to try Maven. For people who have different structures, you will probably also find that their build now works and in these cases I would never recommend switching from Make or Ant unless you are having serious problems with maintenance. 6. Contribute to the code. I have tried to get a foot in the door in order to fix some of my own critisisms, but the lack of javadocs mean that I really can't do this other than for some simple plugins. That is unless I had lots of time to spare which I don't. In turn that makes me concerned how the project will attract other developers to move things along quickly. We have actually attracted more developers in the last 6 months then ever before. We've got 4-5 new developers on the maven project and at least as many on the Mojo project. So things are actually looking
Re: [m2] reasons for sticking with maven
John is basically stating the very thing that I'm against in the statement below. I have a 3rd party command line utility from www.agitar.comhttp://www.agitar.com, that basically does unit tests against our code. I want to write (and have started writing) an M2 plugin to execute the java command line for the agitation process from my plugin. All I need now to complete my plugin besides more hours in a day is a plugin that will allow me to execute a java command line. Now my plugin will integrate with the maven lifecycle during the test phase. However, first I'm told to use the maven-execute-plugin and then another dev states that it's bad and wants to see it eliminated, I'm left thinking WTF!? This *helps* me adopt maven and the process, not hinders it. My whole purpose for writing the plugin was so that I could make the plugin once and the other groups here and else where since I would open source it would be able to reuse it. Is this not what maven is for? Wb On 9/20/05, John Casey [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Snipped] | | 3. Need to do a myriad of simple things such as automatically run java | command or deploy to tomcat. I used to do this all the time in my ant | scripts, ie run my build.xml script and at the end it would run my app | on completion. It's a credit to those on this list who reply with ideas | and workarounds - however this is kind of related to 2 above, where | there are lots of ant tasks out there that are tested to death and that | I should be able to use today. The funny thing about Maven 2 is that it facilitates external plugin development. You can load a plugin from a repository hosted anywhere. Personally, I feel strongly that executing random commands from within the build process is a Bad Thing, and a thing that is bad and common with Ant. Maven - and also Ant, to a lesser extent - is a build tool. It's not a launching platform, and it's not a tool to be used to run your coffee maker. Executing random commands from a configuration in a POM is: a. unscaleable, since that runtime config is not encapsulated for reuse b. bound to partition your build logic into multiple pieces, which now have to be maintained from multiple sources. In Ant, you can do anything you please, including things that don't relate to the process of building software. It's important to keep a clear idea of the problem domain we're trying to address here. Having said that, there's nothing stopping you from hosting your own maven-foo-plugin on Sourceforge or somesuch. If you find what you perceive to be a hole in our plugin offering, and cannot convince us to fill it, there's nothing stopping you from scratching your own itch. We currently have maven-execute-plugin on the mojos project, but I'd really like to see it deprecated and eliminated eventually.
[a4] Build makes Continnum freeze
Hi, Thank you for the alpha-4, it is more complete and the Schedules feature seems like a killer one ! Though, I'm still the same kind of problems as with alpha-3 (precision, I am using Red Hat Linux). The scenario is : * the schedule launches a build * the project is correctly checked-out * nothing more happens * when I type an Enter in the Unix console, I get a : [1]+ Stopped /devel/continuum/continuum/bin/plexus.sh The last words of the log are : 1863652 [Thread-0] INFO org.codehaus.plexus.action.Action:update-project-from-working-directory - Updating project 'Common ATLAS connector' from checkout. 1865216 [Thread-0] WARN org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven2 - Executable '/devel/maven/maven/bin/m2'. 1865216 [Thread-0] INFO org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven2 - Arguments: --batch-mode --non-recursive clean:clean site:site site:deploy install 1865216 [Thread-0] INFO org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven2 - Working directory: /devef/continuum/working/1 Any idea ? Yann ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com
RE: ejb and war plugins (maven 1.1 beta2)
-Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: mardi 20 septembre 2005 18:10 To: Maven Users List Subject: Re: ejb and war plugins (maven 1.1 beta2) He should add a requirement for the war plugin. I'll see with him.. I've just done that and committed the change. Sorry again and thanks guys for fixing this :-) -Vincent On 9/20/05, jan_bar [EMAIL PROTECTED] wrote: Thanks for your time Arnaud, it works for me. Vincent should fix code for http://www.onjava.com/pub/a/onjava/2005/09/07/maven.html?page=4 Jan Arnaud HERITIER [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I published a snapshot you can install it locally maven plugin:download -Dmaven.repo.remote=http:www.ibiblio.org/maven, http://cvs.apache.org/reposit ory/ -DgroupId=maven http://cvs.apache.org/repository/-DgroupId=maven -DartifactId=maven-war-plu gin -Dversion= 1.6.2-SNAPSHOT or you can reference it in your project : in your project.xml : dependency groupIdmaven/groupId artifactIdmaven-war-plugin/artifactId version1.6.2-SNAPSHOT/version typeplugin/type /dependency in your project.properties: maven.repo.remote=http:www.ibiblio.org/maven, http://cvs.apache.org/repository/ Arnaud - 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: [m2] reasons for sticking with maven
-Original Message- From: Wendell Beckwith [mailto:[EMAIL PROTECTED] Sent: mardi 20 septembre 2005 19:15 To: Maven Users List Subject: Re: [m2] reasons for sticking with maven John is basically stating the very thing that I'm against in the statement below. I have a 3rd party command line utility from www.agitar.comhttp://www.agitar.com, that basically does unit tests against our code. I want to write (and have started writing) an M2 plugin to execute the java command line for the agitation process from my plugin. All I need now to complete my plugin besides more hours in a day is a plugin that will allow me to execute a java command line. Now my plugin will integrate with the maven lifecycle during the test phase. However, first I'm told to use the maven-execute-plugin and then another dev states that it's bad and wants to see it eliminated, I'm left thinking WTF!? This *helps* me adopt maven and the process, not hinders it. My whole purpose for writing the plugin was so that I could make the plugin once and the other groups here and else where since I would open source it would be able to reuse it. Is this not what maven is for? Just to muddy the waters: why don't you use commons-exec from your plugin's java code to execute your process? [snip] Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
Probably because I'm not aware of what your talking about. Nonetheless, while there may be another way of doing what I need, the ability to simple specify a command line to a java process that is something that has tremendous capability. Can users overdo it sure, but in an effort to protect clueless users from themselves, should we prevent more advances users/plugin developers from achieving their needs. I'm a big eclipse and firefox user, but I don't dictate that everyone on my team has to do as I do because I believe it is the one true way for IDEs and web browsing. Wb On 9/20/05, Vincent Massol [EMAIL PROTECTED] wrote: -Original Message- From: Wendell Beckwith [mailto:[EMAIL PROTECTED] Sent: mardi 20 septembre 2005 19:15 To: Maven Users List Subject: Re: [m2] reasons for sticking with maven John is basically stating the very thing that I'm against in the statement below. I have a 3rd party command line utility from www.agitar.com http://www.agitar.comhttp://www.agitar.com, that basically does unit tests against our code. I want to write (and have started writing) an M2 plugin to execute the java command line for the agitation process from my plugin. All I need now to complete my plugin besides more hours in a day is a plugin that will allow me to execute a java command line. Now my plugin will integrate with the maven lifecycle during the test phase. However, first I'm told to use the maven-execute-plugin and then another dev states that it's bad and wants to see it eliminated, I'm left thinking WTF!? This *helps* me adopt maven and the process, not hinders it. My whole purpose for writing the plugin was so that I could make the plugin once and the other groups here and else where since I would open source it would be able to reuse it. Is this not what maven is for? Just to muddy the waters: why don't you use commons-exec from your plugin's java code to execute your process? [snip] Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Announcements mailing list
Hello, With the continued development on maven 1.1 and 2.0 and continuum it would be nice to have an announcements mailing list so that people can be notified when things are released. I mean, I'm not a regular user mailing list subscriber and I don't visit the maven site often because maven 1.0.2 Just works for everything that I need it to do. I just happened to be going through all the projects that I'd be interested in being notified of new releases of this morning and happened to see the announcements of maven 2.0 beta1 and continuum alpha4. If I hadn't happened to be looking for an announcements mailing list I never would have known about either of these releases and since I don't regular visit the site or subscribe to the mailing list I probably wouldn't have known for quite some time. Any chance on making this happen? Thanks, Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've actually done something just like this in the past, in order to call a Make-based build. IMO, you want to wrap a command line call in a plugin, to formalize the parameters - required and optional - which constitutes a valid invocation of that executable. Otherwise, it's prone to breaking, misuse, and cut-and-paste maintenance style. In short, it isn't robust, and doesn't scale well. Anything where execution logic is embedded in the POM will suffer from this, IMO - including the antrun and execute plugins in the mojos project. A better solution for Ant would be to build the plugin around the Ant script/scriptlet, and bundle that script into the plugin jar...then parameterize the input configuration. Then, the script can climb the maturity curve, and is truly reused with a single point of maintenance. - -john Vincent Massol wrote: | |-Original Message- |From: Wendell Beckwith [mailto:[EMAIL PROTECTED] |Sent: mardi 20 septembre 2005 19:15 |To: Maven Users List |Subject: Re: [m2] reasons for sticking with maven | |John is basically stating the very thing that I'm against in the statement |below. I have a 3rd party command line utility from |www.agitar.comhttp://www.agitar.com, |that basically does unit tests against our code. I want to write (and have |started writing) an M2 plugin to execute the java command line for the |agitation process from my plugin. All I need now to complete my plugin |besides more hours in a day is a plugin that will allow me to execute a |java |command line. Now my plugin will integrate with the maven lifecycle during |the test phase. However, first I'm told to use the maven-execute-plugin |and |then another dev states that it's bad and wants to see it eliminated, I'm |left thinking WTF!? This *helps* me adopt maven and the process, not |hinders |it. My whole purpose for writing the plugin was so that I could make the |plugin once and the other groups here and else where since I would open |source it would be able to reuse it. Is this not what maven is for? | | | Just to muddy the waters: why don't you use commons-exec from your plugin's | java code to execute your process? | | [snip] | | Thanks | -Vincent | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m 3JIbhwsALTmuwn5OB/7gG9k= =WOfH -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] reasons for sticking with maven
On Tue, 2005-09-20 at 11:52 -0400, Dave Neuer wrote: To which I have to say: why the hell did someone develop surefire in the first place? Short answer: classloader issues. Longer answer is that I wanted something like SuiteRunner which Surefire is based on: http://www.artima.com/suiterunner/ Surefire runs JUnit tests but also has its own notion of a unit of testing called a Battery which easily allows things like scripted testing. There's a Jython battery for example. There's already a perfectly good Ant junit task? It does work perfectly from Ant. Surefire was written a long time ago and Ant's classloading might be fixed now but classloading was one of the primary reasons. And why their own microcontainer? What the heck was wrong w/ Spring (which lots of people already use). Spring was not on the radar when Plexus was started. Plexus came about out of my experience with the Avalon project. That said we are looking at things like Spring and OSGi. It seems to me to be a codehaus thing: a propensity to eschew reuse of other people's code. To a certain extent sure, but there really weren't any mature containers at the time m2 was started. It's been in development longer then most think. So, the upshot is, my plugin doesn't work. It wouldn't work outside of m2 anyway (since m2 plugins don't rely on normal Java mechanisms -- like setter injection, to set their properties) They do now. We felt that was important as other folks have asked that too so we fixed it. so it's not really general as I've heard claimed by some here as an argument why maven plugins are good - loosely coupled to maven. And to make it work, I might have to hack surefire. And plexus. And whatever other 20 wheels have been reinvented rather than reused. We are earnestly trying to roll things in Plexus back into projects like Jakarta Commons. We've done this with the compiler components we've made (which I originally lifted from Cocoon) and our exec code. Slowly we will integrate much of our code back into like Jakarta Commons where things are more easily shared. Much of the reimplementation is due to me lifting stuff and hacking it just to get things to work. Brett has spearheaded the effort to move much of the code used in Maven back to Jakarta from Plexus and it's not an easy task. Ideally what we would like is to have all the utility code in Ant and Plexus back in Jakarta Commons where it can all be maintained for everyone's benefit. I realise that some of the above may be perceived as somewhat inflammatory, but it's really just born out of the frustration of seeing what seems like it should be an easy task -- one which I *can't imagine* I'm the only one requiring -- be so difficult. Fair enough, this is the kind of feedback we need in order to correct the deficiencies. I think the last couple posts by yourself and Ashley are great as you've taken some care in expressing what difficulties you're running into and we can't fix this stuff without feedback. So thanks. And since I don't really have more time to steal from my project to devote to the maven plugin development task, I'm left looking for alternatives, or reluctantly planning to rewrite the build process in Ant buildfiles in the not too distant future. We're usually pretty helpful in IRC and here if you want to toss around ideas. I don't think what you're trying to do would stump us for long if it's not already possible. Respectfully but w/ frustration and confusion, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Announcements mailing list
On Tue, 2005-09-20 at 10:32 -0700, Richard Wallace wrote: Hello, With the continued development on maven 1.1 and 2.0 and continuum it would be nice to have an announcements mailing list so that people can be notified when things are released. I mean, I'm not a regular user mailing list subscriber and I don't visit the maven site often because maven 1.0.2 Just works for everything that I need it to do. I just happened to be going through all the projects that I'd be interested in being notified of new releases of this morning and happened to see the announcements of maven 2.0 beta1 and continuum alpha4. If I hadn't happened to be looking for an announcements mailing list I never would have known about either of these releases and since I don't regular visit the site or subscribe to the mailing list I probably wouldn't have known for quite some time. Any chance on making this happen? We use the announce@apache.org for this. It's relatively low traffic, but we probably won't create an announcement list specifically for Maven itself. Thanks, Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No one is saying you have to follow the party line here. You're free to develop your own maven plugins to solve any problem you like, even run your toaster if you want. Maven will load your plugin, provided you add your groupId to the list of pluginGroups in the settings.xml. We just don't want to be in the business of building a tool to allow non-build activities, because it muddies up our concept of what's really involved with building software. There are multiple boundary considerations for this process, where integrating with maven makes sense, but let's be frank here...they aren't really _build_ process activities. If you're forced to run unit tests via a main() invocation, why not write a unit-test plugin that calls this type of test, and formats errors/output so it can be integrated into the unit tests reporting features, rather than write a plugin that's sole aim is one-off, custom configuration on a per-POM basis, and has no hope of ever being reusable or scalable? I guess I don't understand what's wrong with writing mojos to wrap specific command-line-driven use cases...? - -john Wendell Beckwith wrote: | Probably because I'm not aware of what your talking about. Nonetheless, | while there may be another way of doing what I need, the ability to simple | specify a command line to a java process that is something that has | tremendous capability. Can users overdo it sure, but in an effort to protect | clueless users from themselves, should we prevent more advances users/plugin | developers from achieving their needs. I'm a big eclipse and firefox user, | but I don't dictate that everyone on my team has to do as I do because I | believe it is the one true way for IDEs and web browsing. | | Wb | | On 9/20/05, Vincent Massol [EMAIL PROTECTED] wrote: | | | |-Original Message- |From: Wendell Beckwith [mailto:[EMAIL PROTECTED] |Sent: mardi 20 septembre 2005 19:15 |To: Maven Users List |Subject: Re: [m2] reasons for sticking with maven | |John is basically stating the very thing that I'm against in the | |statement | |below. I have a 3rd party command line utility from |www.agitar.com http://www.agitar.comhttp://www.agitar.com, |that basically does unit tests against our code. I want to write (and | |have | |started writing) an M2 plugin to execute the java command line for the |agitation process from my plugin. All I need now to complete my plugin |besides more hours in a day is a plugin that will allow me to execute a |java |command line. Now my plugin will integrate with the maven lifecycle | |during | |the test phase. However, first I'm told to use the maven-execute-plugin |and |then another dev states that it's bad and wants to see it eliminated, | |I'm | |left thinking WTF!? This *helps* me adopt maven and the process, not |hinders |it. My whole purpose for writing the plugin was so that I could make the |plugin once and the other groups here and else where since I would open |source it would be able to reuse it. Is this not what maven is for? | |Just to muddy the waters: why don't you use commons-exec from your |plugin's |java code to execute your process? | |[snip] | |Thanks |-Vincent | | |- |To unsubscribe, e-mail: [EMAIL PROTECTED] |For additional commands, e-mail: [EMAIL PROTECTED] | | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMEkBK3h2CZwO/4URAkV4AJ91AZVpovMtVrVziGZGb1dBKOQv2wCfSrY9 oShApxHT8sNeu/om38WwQKY= =kv4h -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
Ashley, I recommend that you pull my AntFile Plugin (as a ZIP) from the M2 Jira. I think you will see that this provides exactly what you're asking for -- a simple, clean blending of Ant w/ Maven (Included is an Axis WSDL2Java plugin that demonstrates it's usage pattern). You script with Ant, roll the script into a reusable Plugin, and execute your script (via the Plugin) from the appropriate Maven Phase. Cheers, -- Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
Just for clarification are you suggesting that a plugin that needs to execute a java process should be designed as an ant script, and the plugin would simply pass parameters to the ant script? I ask because I don't see how this is less maintenance than my current plugin that provides intelligent defaults in the mojo and just needs to pass theses parameters along with any the user changed to the java process. Whenever there are plugin changes, I still go to the mojo in my design or an ant script in your design, correct? Wb On 9/20/05, John Casey [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've actually done something just like this in the past, in order to call a Make-based build. IMO, you want to wrap a command line call in a plugin, to formalize the parameters - required and optional - which constitutes a valid invocation of that executable. Otherwise, it's prone to breaking, misuse, and cut-and-paste maintenance style. In short, it isn't robust, and doesn't scale well. Anything where execution logic is embedded in the POM will suffer from this, IMO - including the antrun and execute plugins in the mojos project. A better solution for Ant would be to build the plugin around the Ant script/scriptlet, and bundle that script into the plugin jar...then parameterize the input configuration. Then, the script can climb the maturity curve, and is truly reused with a single point of maintenance. - -john Vincent Massol wrote: | |-Original Message- |From: Wendell Beckwith [mailto:[EMAIL PROTECTED] |Sent: mardi 20 septembre 2005 19:15 |To: Maven Users List |Subject: Re: [m2] reasons for sticking with maven | |John is basically stating the very thing that I'm against in the statement |below. I have a 3rd party command line utility from |www.agitar.com http://www.agitar.comhttp://www.agitar.com, |that basically does unit tests against our code. I want to write (and have |started writing) an M2 plugin to execute the java command line for the |agitation process from my plugin. All I need now to complete my plugin |besides more hours in a day is a plugin that will allow me to execute a |java |command line. Now my plugin will integrate with the maven lifecycle during |the test phase. However, first I'm told to use the maven-execute-plugin |and |then another dev states that it's bad and wants to see it eliminated, I'm |left thinking WTF!? This *helps* me adopt maven and the process, not |hinders |it. My whole purpose for writing the plugin was so that I could make the |plugin once and the other groups here and else where since I would open |source it would be able to reuse it. Is this not what maven is for? | | | Just to muddy the waters: why don't you use commons-exec from your plugin's | java code to execute your process? | | [snip] | | Thanks | -Vincent | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m 3JIbhwsALTmuwn5OB/7gG9k= =WOfH -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Announcements mailing list
Jason van Zyl wrote: We use the announce@apache.org for this. It's relatively low traffic, but we probably won't create an announcement list specifically for Maven itself. Ah I see. Didn't know that. Should probably be mentioned on the mailing lists page for people like me. Guess I'll go subscribe to that one. Thanks again, Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was actually referring to a couple of implementation patterns. 1. Wrap a command-line invocation. ~ Using commons-exec or any other Runtime.exec() wrapper, you can build a mojo that will pull in parameters from the Maven build process, format the command line, and execute...hopefully with output/error handling for that specific command. 2. Provide a plugin wrapper for an Ant script. ~ Using a given Ant script, bundle that script into a maven plugin whose functionality is centered on that single script. Again, maven provides the parameters from the build process, and passes them to the script/target in that plugin's embedded Ant script. Again, output/errors are handled in a way that is tuned to the task at hand. It's important to understand the specificity of these solutions. If you're using a general directly-embedded-Ant-inside-the-POM solution, you cannot handle output or errors in an intelligent manner. Same with a command-line-inside-the-POM solution. Moreover, in each of these inline solutions, your specific command-line or Ant invocation is confined to that POM and possibly its descendents, via inheritance. You cannot reuse this configuration outside the POM without incurring the costs of maintenance associated with cut-and-paste programming of any kind (i.e. multiple maintenance points, propagation of erroneous code, etc.). I'm not familiar with the plugin you've written, but I think the above statements apply generally. If you're already following those principles, I'd like to see what you have. I've been heads-down lately, so I may have missed the thread in which you were talking about it... Of course, using (or abusing) the maven plugin framework, you can do almost anything. Just don't ask me to maintain it or support it... :) Cheers, john Wendell Beckwith wrote: | Just for clarification are you suggesting that a plugin that needs to | execute a java process should be designed as an ant script, and the plugin | would simply pass parameters to the ant script? I ask because I don't see | how this is less maintenance than my current plugin that provides | intelligent defaults in the mojo and just needs to pass theses parameters | along with any the user changed to the java process. Whenever there are | plugin changes, I still go to the mojo in my design or an ant script in your | design, correct? | | Wb | | | On 9/20/05, John Casey [EMAIL PROTECTED] wrote: | | I've actually done something just like this in the past, in order to | call a Make-based build. IMO, you want to wrap a command line call in a | plugin, to formalize the parameters - required and optional - which | constitutes a valid invocation of that executable. Otherwise, it's prone | to breaking, misuse, and cut-and-paste maintenance style. In short, it | isn't robust, and doesn't scale well. Anything where execution logic is | embedded in the POM will suffer from this, IMO - including the antrun | and execute plugins in the mojos project. A better solution for Ant | would be to build the plugin around the Ant script/scriptlet, and bundle | that script into the plugin jar...then parameterize the input | configuration. Then, the script can climb the maturity curve, and is | truly reused with a single point of maintenance. | | -john | | Vincent Massol wrote: | | | |-Original Message- | |From: Wendell Beckwith [mailto:[EMAIL PROTECTED] | |Sent: mardi 20 septembre 2005 19:15 | |To: Maven Users List | |Subject: Re: [m2] reasons for sticking with maven | | | |John is basically stating the very thing that I'm against in the | statement | |below. I have a 3rd party command line utility from | |www.agitar.com http://www.agitar.comhttp://www.agitar.com, | |that basically does unit tests against our code. I want to write (and | have | |started writing) an M2 plugin to execute the java command line for the | |agitation process from my plugin. All I need now to complete my plugin | |besides more hours in a day is a plugin that will allow me to execute a | |java | |command line. Now my plugin will integrate with the maven lifecycle | during | |the test phase. However, first I'm told to use the maven-execute-plugin | |and | |then another dev states that it's bad and wants to see it eliminated, | I'm | |left thinking WTF!? This *helps* me adopt maven and the process, not | |hinders | |it. My whole purpose for writing the plugin was so that I could make the | |plugin once and the other groups here and else where since I would open | |source it would be able to reuse it. Is this not what maven is for? | | | | | | Just to muddy the waters: why don't you use commons-exec from your | plugin's | | java code to execute your process? | | | | [snip] | | | | Thanks | | -Vincent | | | | | | - | | To unsubscribe, e-mail: [EMAIL PROTECTED] | | For additional commands, e-mail: [EMAIL PROTECTED] | | | | | | -
Re: [m2] reasons for sticking with maven
Dave Neuer wrote: However, I don't like having no ability to reuse test code from one project in another project which depends on it. Example: project A has interface Blah and interface BlahDAO to persist blahs. I have AbstractBlahDAOTest which has testXXX methods which test *interface invariant* conditions of BlahDAO. Project B has a new subclass of Blah and BlahDAO, but it's ProjectBBlahDAO *must* still abide by the interface invariant constraints. So I want to have ProjectBBlahDAOTest which extends AbstractBlahDAOTest from project A, but I can't because I can't generate another (test) artifact in maven. We experienced similar problems in Cocoon - our workaround is to add another project A-test which contains the all test classes as its source. Then B can depend on A-test with scope test. But I think this is only a workaround. It would be great if this could be solved somehow in m2 without any tricks. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
I just re-read you email and I'm confused by your comment, please clarify if possible. But isn't what I've been hopefully explaining is the creation of a mojo that wraps a command line process. I have written the mojos (agitate and dashboard) an users only need to reference the plugin in their build element. If the defaults are right for them, say they have a 80% code coverage target instead of the default of 70% then they can add a coverage element to the configuration element for the plugin. Now the plugin takes the prams and puts then in the correct order and that is where I'm currently am. I would like to have a maven-java-plugin or something like it that my plugin can depend on to actually execute the process and tie its output stdout and stderr back to my process. That's all I need. I'm not advocating giving users the ability to execute any java command from their pom. This is my 1st m2 plugin so if I'm now one of those clueless users, then please correct me where I'm wrong. Wb On 9/20/05, John Casey [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I guess I don't understand what's wrong with writing mojos to wrap specific command-line-driven use cases...? - -john
Re: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 that sounds perfectly sane, except it sounds like you only need an API for calling a java main() method and handling output than an actual plugin. Once you have that API, you're set, it sounds like...then your plugin can depend on that api, and give it the stream consumers for sterr/stout and stream provider for stdin, I guess. I suppose I misunderstood where you were going with the maven-java-plugin. You're after more of a main() support API than an actual java-plugin, since you're writing the plugin yourself. Correct? - -john Wendell Beckwith wrote: | I just re-read you email and I'm confused by your comment, please clarify if | possible. But isn't what I've been hopefully explaining is the creation of a | mojo that wraps a command line process. I have written the mojos (agitate | and dashboard) an users only need to reference the plugin in their build | element. If the defaults are right for them, say they have a 80% code | coverage target instead of the default of 70% then they can add a coverage | element to the configuration element for the plugin. Now the plugin takes | the prams and puts then in the correct order and that is where I'm currently | am. I would like to have a maven-java-plugin or something like it that my | plugin can depend on to actually execute the process and tie its output | stdout and stderr back to my process. That's all I need. I'm not advocating | giving users the ability to execute any java command from their pom. | | This is my 1st m2 plugin so if I'm now one of those clueless users, then | please correct me where I'm wrong. | | Wb | On 9/20/05, John Casey [EMAIL PROTECTED] wrote: | |-BEGIN PGP SIGNED MESSAGE- |Hash: SHA1 | | |I guess I don't understand what's wrong with writing mojos to wrap |specific command-line-driven use cases...? | |- -john | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMFEWK3h2CZwO/4URAveWAKCDHwHQN8WHKYx0V7YtI1mto4x4mgCdG+v9 pTLGzK9uJsmhto/wMtt1+vo= =NYSU -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote: I just re-read you email and I'm confused by your comment, please clarify if possible. But isn't what I've been hopefully explaining is the creation of a mojo that wraps a command line process. I have written the mojos (agitate and dashboard) an users only need to reference the plugin in their build element. If the defaults are right for them, say they have a 80% code coverage target instead of the default of 70% then they can add a coverage element to the configuration element for the plugin. Now the plugin takes the prams and puts then in the correct order and that is where I'm currently am. I would like to have a maven-java-plugin or something like it that my plugin can depend on to actually execute the process and tie its output stdout and stderr back to my process. That's all I need. I'm not advocating giving users the ability to execute any java command from their pom. For now, until all the hot air in commons-exec stabilizes take a look at plexus-utils and the org.codehaus.plexus.util.cli package. For a simple example take a look at [1]. [1]: http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315view=markup -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
YES!! That is exactly what I need/want. Sorry if I wasn't clear before, but I'm definitely not for the embedding of command lines in he pom. Now that I understand where you're coming from, I can completely agree with you that embedding this stuff in a pom would definitely lead to cut-n-paste code which s why I'm actively moving nearly 100 dev's from ant to maven 2 starting with my project. Wb On 9/20/05, John Casey [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 that sounds perfectly sane, except it sounds like you only need an API for calling a java main() method and handling output than an actual plugin. Once you have that API, you're set, it sounds like...then your plugin can depend on that api, and give it the stream consumers for sterr/stout and stream provider for stdin, I guess. I suppose I misunderstood where you were going with the maven-java-plugin. You're after more of a main() support API than an actual java-plugin, since you're writing the plugin yourself. Correct? - -john Wendell Beckwith wrote: | I just re-read you email and I'm confused by your comment, please clarify if | possible. But isn't what I've been hopefully explaining is the creation of a | mojo that wraps a command line process. I have written the mojos (agitate | and dashboard) an users only need to reference the plugin in their build | element. If the defaults are right for them, say they have a 80% code | coverage target instead of the default of 70% then they can add a coverage | element to the configuration element for the plugin. Now the plugin takes | the prams and puts then in the correct order and that is where I'm currently | am. I would like to have a maven-java-plugin or something like it that my | plugin can depend on to actually execute the process and tie its output | stdout and stderr back to my process. That's all I need. I'm not advocating | giving users the ability to execute any java command from their pom. | | This is my 1st m2 plugin so if I'm now one of those clueless users, then | please correct me where I'm wrong. | | Wb | On 9/20/05, John Casey [EMAIL PROTECTED] wrote: | |-BEGIN PGP SIGNED MESSAGE- |Hash: SHA1 | | |I guess I don't understand what's wrong with writing mojos to wrap |specific command-line-driven use cases...? | |- -john | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMFEWK3h2CZwO/4URAveWAKCDHwHQN8WHKYx0V7YtI1mto4x4mgCdG+v9 pTLGzK9uJsmhto/wMtt1+vo= =NYSU -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 it's not a command line execution...it's a java main() call...right? Trygve Laugstøl wrote: | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote: | |I just re-read you email and I'm confused by your comment, please clarify if |possible. But isn't what I've been hopefully explaining is the creation of a |mojo that wraps a command line process. I have written the mojos (agitate |and dashboard) an users only need to reference the plugin in their build |element. If the defaults are right for them, say they have a 80% code |coverage target instead of the default of 70% then they can add a coverage |element to the configuration element for the plugin. Now the plugin takes |the prams and puts then in the correct order and that is where I'm currently |am. I would like to have a maven-java-plugin or something like it that my |plugin can depend on to actually execute the process and tie its output |stdout and stderr back to my process. That's all I need. I'm not advocating |giving users the ability to execute any java command from their pom. | | | For now, until all the hot air in commons-exec stabilizes take a look at | plexus-utils and the org.codehaus.plexus.util.cli package. For a simple | example take a look at [1]. | | [1]: | http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315view=markup | | -- | Trygve | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMFI/K3h2CZwO/4URAvoXAKCpFFlfc7CDSG35HygJdqAN0aHfbgCeMMzA bc1WTt3I4WBoJycsmRICNXc= =rA82 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 so, all that remains is to write that API that you need :-) I've been thinking that we may need a sub-project within maven (with separated release cycle) to address plugin utility libraries...constructing a classloader from the project dependencies, executing main() methods in an isolated classloader, etc. The plugins are going to start writing their own parallel infrastructure (and have in some cases) unless we can centralize it in a series of plugin support artifacts. WDYT? Do you want to start a design doc for that API you need? just a statement of the different things it needs to do would be a good start... - --john Wendell Beckwith wrote: | YES!! That is exactly what I need/want. Sorry if I wasn't clear before, but | I'm definitely not for the embedding of command lines in he pom. Now that I | understand where you're coming from, I can completely agree with you that | embedding this stuff in a pom would definitely lead to cut-n-paste code | which s why I'm actively moving nearly 100 dev's from ant to maven 2 | starting with my project. | | Wb | | On 9/20/05, John Casey [EMAIL PROTECTED] wrote: | | that sounds perfectly sane, except it sounds like you only need an API | for calling a java main() method and handling output than an actual | plugin. Once you have that API, you're set, it sounds like...then your | plugin can depend on that api, and give it the stream consumers for | sterr/stout and stream provider for stdin, I guess. | | I suppose I misunderstood where you were going with the | maven-java-plugin. You're after more of a main() support API than an | actual java-plugin, since you're writing the plugin yourself. Correct? | | -john | | Wendell Beckwith wrote: | | I just re-read you email and I'm confused by your comment, please | clarify if | | possible. But isn't what I've been hopefully explaining is the | creation of a | | mojo that wraps a command line process. I have written the mojos | (agitate | | and dashboard) an users only need to reference the plugin in their build | | element. If the defaults are right for them, say they have a 80% code | | coverage target instead of the default of 70% then they can add a | coverage | | element to the configuration element for the plugin. Now the plugin | takes | | the prams and puts then in the correct order and that is where I'm | currently | | am. I would like to have a maven-java-plugin or something like it that | my | | plugin can depend on to actually execute the process and tie its output | | stdout and stderr back to my process. That's all I need. I'm not | advocating | | giving users the ability to execute any java command from their pom. | | | | This is my 1st m2 plugin so if I'm now one of those clueless users, then | | please correct me where I'm wrong. | | | | Wb | | On 9/20/05, John Casey [EMAIL PROTECTED] wrote: | | | |-BEGIN PGP SIGNED MESSAGE- | |Hash: SHA1 | | | | | |I guess I don't understand what's wrong with writing mojos to wrap | |specific command-line-driven use cases...? | | | |- -john | | | | | | - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMFU/K3h2CZwO/4URAqnnAKCs5kWQ/8rkJHwUP4F8ZpMI07Lq4ACeNmbg ygQnRvqcld3CuQ/4MuZZfbU= =LOuS -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, fair enough...but the maven process should probably install a security manager to restrict who can call System.exit(..) (i.e. no-one can! :) But there is still the potential for issues surrounding OutOfMemoryError's and the like. If you're going the route of using a separate java process, then you should check into commons-exec. I haven't used it, but if it's the stuff extracted from Ant (and plexus, actually), then it'll be suitable. - -john Wendell Beckwith wrote: | True, it is a java main() call because the use ZeroG's LaunchAnywhere. | LaunchAnywhere creates a native executable that reads a config file that | lists the classpath, args and the main class to execute. However because I | didn't write the code nor do have the source code, I don't know if the code | somewhere will call System.exit(). If it does then my maven process is dead, | which is why I want the ability to run this java main() in a separate | process. Makes sense? | | Wb | | On 9/20/05, John Casey [EMAIL PROTECTED] wrote: | | it's not a command line execution...it's a java main() call...right? | | Trygve Laugstøl wrote: | | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote: | | | |I just re-read you email and I'm confused by your comment, please | clarify if | |possible. But isn't what I've been hopefully explaining is the | creation of a | |mojo that wraps a command line process. I have written the mojos | (agitate | |and dashboard) an users only need to reference the plugin in their build | |element. If the defaults are right for them, say they have a 80% code | |coverage target instead of the default of 70% then they can add a | coverage | |element to the configuration element for the plugin. Now the plugin | takes | |the prams and puts then in the correct order and that is where I'm | currently | |am. I would like to have a maven-java-plugin or something like it that | my | |plugin can depend on to actually execute the process and tie its output | |stdout and stderr back to my process. That's all I need. I'm not | advocating | |giving users the ability to execute any java command from their pom. | | | | | | For now, until all the hot air in commons-exec stabilizes take a look at | | plexus-utils and the org.codehaus.plexus.util.cli package. For a simple | | example take a look at [1]. | | | | [1]: | | | | http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315view=markup | | | | -- | | Trygve | | | | | | - | | 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] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMFXBK3h2CZwO/4URAvkbAJ4ir8+/w7fgWCTfH6XA0bgXLW2rmQCeKqh+ 6H/krj8A/paO61kOgt4MHNU= =Lywd -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
I will look into commons-exec since I wasn't aware of it and thnx for all the help. Wb On 9/20/05, John Casey [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, fair enough...but the maven process should probably install a security manager to restrict who can call System.exit(..) (i.e. no-one can! :) But there is still the potential for issues surrounding OutOfMemoryError's and the like. If you're going the route of using a separate java process, then you should check into commons-exec. I haven't used it, but if it's the stuff extracted from Ant (and plexus, actually), then it'll be suitable. - -john Wendell Beckwith wrote: | True, it is a java main() call because the use ZeroG's LaunchAnywhere. | LaunchAnywhere creates a native executable that reads a config file that | lists the classpath, args and the main class to execute. However because I | didn't write the code nor do have the source code, I don't know if the code | somewhere will call System.exit(). If it does then my maven process is dead, | which is why I want the ability to run this java main() in a separate | process. Makes sense? | | Wb | | On 9/20/05, John Casey [EMAIL PROTECTED] wrote: | | it's not a command line execution...it's a java main() call...right? | | Trygve Laugstøl wrote: | | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote: | | | |I just re-read you email and I'm confused by your comment, please | clarify if | |possible. But isn't what I've been hopefully explaining is the | creation of a | |mojo that wraps a command line process. I have written the mojos | (agitate | |and dashboard) an users only need to reference the plugin in their build | |element. If the defaults are right for them, say they have a 80% code | |coverage target instead of the default of 70% then they can add a | coverage | |element to the configuration element for the plugin. Now the plugin | takes | |the prams and puts then in the correct order and that is where I'm | currently | |am. I would like to have a maven-java-plugin or something like it that | my | |plugin can depend on to actually execute the process and tie its output | |stdout and stderr back to my process. That's all I need. I'm not | advocating | |giving users the ability to execute any java command from their pom. | | | | | | For now, until all the hot air in commons-exec stabilizes take a look at | | plexus-utils and the org.codehaus.plexus.util.cli package. For a simple | | example take a look at [1]. | | | | [1]: | | | | http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315view=markup | | | | -- | | Trygve | | | | | | - | | 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] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMFXBK3h2CZwO/4URAvkbAJ4ir8+/w7fgWCTfH6XA0bgXLW2rmQCeKqh+ 6H/krj8A/paO61kOgt4MHNU= =Lywd -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] reasons for sticking with maven
Yes, that's a workaround I'm not OK with, so a developer cannot be in
/masterProject/projectA and do m2 test, see BUILD SUCCESSFUL and think
that everything is OK and check in a bunch of broken code because no
tests
were run -- since the tests for A don't live in A.
Again, I did write a maven-test-artfiact plugin which has a compile and
install target; it *does* generate a test artifact (default name
${artifactId}-test.${packaging}, but it's configurable.
However, it doesn't generate a POM, and even w/ a manually generated
one, and a declared dependancy on A's test artifact in project B,
surefire doesn't run the tests in the baseclasses which reside in the
test.jar.
That's where I got, and where I ran out of patience and time to keep
going. I'd be happy to ask my manager if we can release this code if
someone else were interested in running w/ it.
Dave
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 20, 2005 2:05 PM
To: Maven Users List
Subject: Re: [m2] reasons for sticking with maven
Dave Neuer wrote:
However, I don't like having no ability to reuse test code from one
project in another project which depends on it. Example: project A has
interface Blah and interface BlahDAO to persist blahs. I have
AbstractBlahDAOTest which has testXXX methods which test *interface
invariant* conditions of BlahDAO. Project B has a new subclass of Blah
and BlahDAO, but it's ProjectBBlahDAO *must* still abide by the
interface invariant constraints. So I want to have ProjectBBlahDAOTest
which extends AbstractBlahDAOTest from project A, but I can't because
I
can't generate another (test) artifact in maven.
We experienced similar problems in Cocoon - our workaround is to add
another
project A-test which contains the all test classes as its source. Then B
can depend on A-test with scope test. But I think this is only a
workaround. It would be great if this could be solved somehow in m2
without any tricks.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
-
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: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 any time. Wendell Beckwith wrote: | I will look into commons-exec since I wasn't aware of it and thnx for all | the help. | | Wb | | | On 9/20/05, John Casey [EMAIL PROTECTED] wrote: | | Ok, fair enough...but the maven process should probably install a | security manager to restrict who can call System.exit(..) (i.e. no-one | can! :) | | But there is still the potential for issues surrounding | OutOfMemoryError's and the like. If you're going the route of using a | separate java process, then you should check into commons-exec. I | haven't used it, but if it's the stuff extracted from Ant (and plexus, | actually), then it'll be suitable. | | -john | | Wendell Beckwith wrote: | | True, it is a java main() call because the use ZeroG's LaunchAnywhere. | | LaunchAnywhere creates a native executable that reads a config file that | | lists the classpath, args and the main class to execute. However because | I | | didn't write the code nor do have the source code, I don't know if the | code | | somewhere will call System.exit(). If it does then my maven process is | dead, | | which is why I want the ability to run this java main() in a separate | | process. Makes sense? | | | | Wb | | | | On 9/20/05, John Casey [EMAIL PROTECTED] wrote: | | | | it's not a command line execution...it's a java main() call...right? | | | | Trygve Laugstøl wrote: | | | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote: | | | | | |I just re-read you email and I'm confused by your comment, please | | clarify if | | |possible. But isn't what I've been hopefully explaining is the | | creation of a | | |mojo that wraps a command line process. I have written the mojos | | (agitate | | |and dashboard) an users only need to reference the plugin in their | build | | |element. If the defaults are right for them, say they have a 80% code | | |coverage target instead of the default of 70% then they can add a | | coverage | | |element to the configuration element for the plugin. Now the plugin | | takes | | |the prams and puts then in the correct order and that is where I'm | | currently | | |am. I would like to have a maven-java-plugin or something like it that | | my | | |plugin can depend on to actually execute the process and tie its | output | | |stdout and stderr back to my process. That's all I need. I'm not | | advocating | | |giving users the ability to execute any java command from their pom. | | | | | | | | | For now, until all the hot air in commons-exec stabilizes take a look | at | | | plexus-utils and the org.codehaus.plexus.util.cli package. For a | simple | | | example take a look at [1]. | | | | | | [1]: | | | | | | | | | http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315view=markup | | | | | | -- | | | Trygve | | | | | | | | | - | | | 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] | | | | - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMFgcK3h2CZwO/4URAqg6AKCq6uJle+9PgQ+6gti1z0VqYTpkCACcCm04 YnPgnOM3sD7nf+8iecubZys= =BS9H -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
On Tue, 2005-09-20 at 14:30 -0400, John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 so, all that remains is to write that API that you need :-) I've been thinking that we may need a sub-project within maven (with separated release cycle) to address plugin utility libraries...constructing a classloader from the project dependencies, executing main() methods in an isolated classloader, etc. The plugins are going to start writing their own parallel infrastructure (and have in some cases) unless we can centralize it in a series of plugin support artifacts. WDYT? Do you want to start a design doc for that API you need? just a statement of the different things it needs to do would be a good start... You have my preliminary +1 at least. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
Dave Neuer wrote:
Yes, that's a workaround I'm not OK with, so a developer cannot be in
/masterProject/projectA and do m2 test, see BUILD SUCCESSFUL and think
that everything is OK and check in a bunch of broken code because no
tests
were run -- since the tests for A don't live in A.
Oh no, they are still in A - that's trick :) (ok, one could call it
hack). You have the correct pom for A containing the tests. You make a
sub directory in project A: tests-for-b, add a pom.xml there
referencing the tests of A as src (using ../) and then it works.
Again, I did write a maven-test-artfiact plugin which has a compile and
install target; it *does* generate a test artifact (default name
${artifactId}-test.${packaging}, but it's configurable.
However, it doesn't generate a POM, and even w/ a manually generated
one, and a declared dependancy on A's test artifact in project B,
surefire doesn't run the tests in the baseclasses which reside in the
test.jar.
That's where I got, and where I ran out of patience and time to keep
going. I'd be happy to ask my manager if we can release this code if
someone else were interested in running w/ it.
It would be interesting to hear what the m2 developers say about this
problem :)
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
Isn't this covered by http://jira.codehaus.org/browse/MNG-932 ?
Mark
On 20/09/05, John Casey [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Another solution might be an attached artifact (logically attached to
the main .jar in the repository via the metadata) that would be
available to other projects...so producing project A might also produce:
a-version-tests.jar
and you could then depend on it like such:
dependency
~ groupIdsome.group/groupId
~ artifactIda/artifactId
~ versionsomeVersion/version
~ typetest-jar/type
~ scopetest/scope
/dependency
would that solve the problem?
- -john
Carsten Ziegeler wrote:
| Dave Neuer wrote:
|
|Yes, that's a workaround I'm not OK with, so a developer cannot be in
|/masterProject/projectA and do m2 test, see BUILD SUCCESSFUL and think
|that everything is OK and check in a bunch of broken code because no
|tests
|were run -- since the tests for A don't live in A.
|
|
| Oh no, they are still in A - that's trick :) (ok, one could call it
| hack). You have the correct pom for A containing the tests. You make a
| sub directory in project A: tests-for-b, add a pom.xml there
| referencing the tests of A as src (using ../) and then it works.
|
|
|Again, I did write a maven-test-artfiact plugin which has a compile and
|install target; it *does* generate a test artifact (default name
|${artifactId}-test.${packaging}, but it's configurable.
|
|However, it doesn't generate a POM, and even w/ a manually generated
|one, and a declared dependancy on A's test artifact in project B,
|surefire doesn't run the tests in the baseclasses which reside in the
|test.jar.
|
|That's where I got, and where I ran out of patience and time to keep
|going. I'd be happy to ask my manager if we can release this code if
|someone else were interested in running w/ it.
|
|
| It would be interesting to hear what the m2 developers say about this
| problem :)
|
| Carsten
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMFs1K3h2CZwO/4URAq1eAJwMu6k7TkUiR25AcmxtHAGm77U26wCfRiBh
uTSibc3Gno8WdJEABwrM6BM=
=6B7J
-END PGP SIGNATURE-
-
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: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yeah, that looks like it. I wasn't aware of that issue...too new, I guess :)
Thanks, Mark.
john
Mark Hobson wrote:
| Isn't this covered by http://jira.codehaus.org/browse/MNG-932 ?
|
| Mark
|
| On 20/09/05, John Casey [EMAIL PROTECTED] wrote:
|
| Another solution might be an attached artifact (logically attached to
| the main .jar in the repository via the metadata) that would be
| available to other projects...so producing project A might also produce:
|
| a-version-tests.jar
|
| and you could then depend on it like such:
|
| dependency
| ~ groupIdsome.group/groupId
| ~ artifactIda/artifactId
| ~ versionsomeVersion/version
| ~ typetest-jar/type
| ~ scopetest/scope
| /dependency
|
| would that solve the problem?
|
| -john
|
| Carsten Ziegeler wrote:
| | Dave Neuer wrote:
| |
| |Yes, that's a workaround I'm not OK with, so a developer cannot be in
| |/masterProject/projectA and do m2 test, see BUILD SUCCESSFUL and think
| |that everything is OK and check in a bunch of broken code because no
| |tests
| |were run -- since the tests for A don't live in A.
| |
| |
| | Oh no, they are still in A - that's trick :) (ok, one could call it
| | hack). You have the correct pom for A containing the tests. You make a
| | sub directory in project A: tests-for-b, add a pom.xml there
| | referencing the tests of A as src (using ../) and then it works.
| |
| |
| |Again, I did write a maven-test-artfiact plugin which has a compile and
| |install target; it *does* generate a test artifact (default name
| |${artifactId}-test.${packaging}, but it's configurable.
| |
| |However, it doesn't generate a POM, and even w/ a manually generated
| |one, and a declared dependancy on A's test artifact in project B,
| |surefire doesn't run the tests in the baseclasses which reside in the
| |test.jar.
| |
| |That's where I got, and where I ran out of patience and time to keep
| |going. I'd be happy to ask my manager if we can release this code if
| |someone else were interested in running w/ it.
| |
| |
| | It would be interesting to hear what the m2 developers say about this
| | problem :)
| |
| | Carsten
| |
- -
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]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMFyrK3h2CZwO/4URAmdkAJ9EtnA8+4q/E1y9vFW/qCzlrPueRgCeJ2Ho
OImXL7E2wJ3HxevjML4egXg=
=F56A
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] reasons for sticking with maven
Created: Today 08:00 AM.
That is exactly what I'm talking about.
I would have been happy to ask about donating my code, but it's unclear
to me from the referenced JIRA entry whether they're talking about
making the regular compile and install plugins do the test artifact
generation (plus making sure that surefire can run the tests -- as I
said, it didn't seem to be able to run tests from a base class in a
separate jar).
Personally, I think that this would be a common enough feature that it
really belongs in the compile and install plugins, rather than a
standalone plugin like the one I developed.
e.g.
groupIdmy.project/groupId
artifactIdmain-artifact/artifactId
testArtifactIdmain-test-artifact/testArtifactId
and then depend on it in the manner John specified.
Dave
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 20, 2005 3:02 PM
To: Maven Users List
Subject: Re: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yeah, that looks like it. I wasn't aware of that issue...too new, I
guess :)
Thanks, Mark.
john
Mark Hobson wrote:
| Isn't this covered by http://jira.codehaus.org/browse/MNG-932 ?
|
| Mark
|
| On 20/09/05, John Casey [EMAIL PROTECTED] wrote:
|
| Another solution might be an attached artifact (logically attached to
| the main .jar in the repository via the metadata) that would be
| available to other projects...so producing project A might also
produce:
|
| a-version-tests.jar
|
| and you could then depend on it like such:
|
| dependency
| ~ groupIdsome.group/groupId
| ~ artifactIda/artifactId
| ~ versionsomeVersion/version
| ~ typetest-jar/type
| ~ scopetest/scope
| /dependency
|
| would that solve the problem?
|
| -john
|
| Carsten Ziegeler wrote:
| | Dave Neuer wrote:
| |
| |Yes, that's a workaround I'm not OK with, so a developer cannot be
in
| |/masterProject/projectA and do m2 test, see BUILD SUCCESSFUL and
think
| |that everything is OK and check in a bunch of broken code because no
| |tests
| |were run -- since the tests for A don't live in A.
| |
| |
| | Oh no, they are still in A - that's trick :) (ok, one could call it
| | hack). You have the correct pom for A containing the tests. You make
a
| | sub directory in project A: tests-for-b, add a pom.xml there
| | referencing the tests of A as src (using ../) and then it works.
| |
| |
| |Again, I did write a maven-test-artfiact plugin which has a compile
and
| |install target; it *does* generate a test artifact (default name
| |${artifactId}-test.${packaging}, but it's configurable.
| |
| |However, it doesn't generate a POM, and even w/ a manually generated
| |one, and a declared dependancy on A's test artifact in project B,
| |surefire doesn't run the tests in the baseclasses which reside in
the
| |test.jar.
| |
| |That's where I got, and where I ran out of patience and time to keep
| |going. I'd be happy to ask my manager if we can release this code if
| |someone else were interested in running w/ it.
| |
| |
| | It would be interesting to hear what the m2 developers say about
this
| | problem :)
| |
| | Carsten
| |
- -
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]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMFyrK3h2CZwO/4URAmdkAJ9EtnA8+4q/E1y9vFW/qCzlrPueRgCeJ2Ho
OImXL7E2wJ3HxevjML4egXg=
=F56A
-END PGP SIGNATURE-
-
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: [m2] assembly plugin + a few instructions
Ashley Williams wrote: I was expecting the jars from my dependencies section to be there. [...] Which resulted in a compressed file(s) containing my jar file and its dependencies. I was then able to uncompress it and launch with the java -jar command. Well, you should have tried the descriptorId jar-with-dependencies. It seems to me that this would have created a jar that should fit your needs. Daniel Schömer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] assembly plugin + a few instructions
Ok, the name of the file may suggest that it would achieve my goals, but in practice it doesn't. I did give it a go and it resulted in all my jar dependencies being unpacked - definitely not what I want. Looking at the xml the line which does this is: unpacktrue/unpack Additionally it causes a jar file to be generated whereas I want something like a tar. None of the three assembly files suit me which is why I had to tailor my own Thanks AW On 20 Sep 2005, at 20:21, Daniel Schömer wrote: Ashley Williams wrote: I was expecting the jars from my dependencies section to be there. [...] Which resulted in a compressed file(s) containing my jar file and its dependencies. I was then able to uncompress it and launch with the java -jar command. Well, you should have tried the descriptorId jar-with-dependencies. It seems to me that this would have created a jar that should fit your needs. Daniel Schömer - 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: [m2] reasons for sticking with maven
Yes, it is the equivalent. But one thing confuses me, it's not about executing a java process (per se) -- it's about executing Ant. And it's not about maintenance. I think the heart of the discussion is reuse. Not reinventing what Ant already does. Providing a mechanism for reuse and versioning of Ant scripts. Reusing Ant scripts (or pieces of them) from existing builds, when converting to Maven. To the plugin developer, they can simply build an Ant script as they always do, and a simple Mojo that passes parameters (and defaults) from the POM in to the Ant script and executes it. Obviously, I could have done it all within the Mojo myself, or I could have called Ant programmatically, or I could just script the Ant. There are many ways to get there. To the plugin user, they don't know which technique is in use, and shouldn't care... On 9/20/05, Wendell Beckwith [EMAIL PROTECTED] wrote: Just for clarification are you suggesting that a plugin that needs to execute a java process should be designed as an ant script, and the plugin would simply pass parameters to the ant script? I ask because I don't see how this is less maintenance than my current plugin that provides intelligent defaults in the mojo and just needs to pass theses parameters along with any the user changed to the java process. Whenever there are plugin changes, I still go to the mojo in my design or an ant script in your design, correct? Wb On 9/20/05, John Casey [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've actually done something just like this in the past, in order to call a Make-based build. IMO, you want to wrap a command line call in a plugin, to formalize the parameters - required and optional - which constitutes a valid invocation of that executable. Otherwise, it's prone to breaking, misuse, and cut-and-paste maintenance style. In short, it isn't robust, and doesn't scale well. Anything where execution logic is embedded in the POM will suffer from this, IMO - including the antrun and execute plugins in the mojos project. A better solution for Ant would be to build the plugin around the Ant script/scriptlet, and bundle that script into the plugin jar...then parameterize the input configuration. Then, the script can climb the maturity curve, and is truly reused with a single point of maintenance. - -john Vincent Massol wrote: | |-Original Message- |From: Wendell Beckwith [mailto:[EMAIL PROTECTED] |Sent: mardi 20 septembre 2005 19:15 |To: Maven Users List |Subject: Re: [m2] reasons for sticking with maven | |John is basically stating the very thing that I'm against in the statement |below. I have a 3rd party command line utility from |www.agitar.com http://www.agitar.comhttp://www.agitar.com, |that basically does unit tests against our code. I want to write (and have |started writing) an M2 plugin to execute the java command line for the |agitation process from my plugin. All I need now to complete my plugin |besides more hours in a day is a plugin that will allow me to execute a |java |command line. Now my plugin will integrate with the maven lifecycle during |the test phase. However, first I'm told to use the maven-execute-plugin |and |then another dev states that it's bad and wants to see it eliminated, I'm |left thinking WTF!? This *helps* me adopt maven and the process, not |hinders |it. My whole purpose for writing the plugin was so that I could make the |plugin once and the other groups here and else where since I would open |source it would be able to reuse it. Is this not what maven is for? | | | Just to muddy the waters: why don't you use commons-exec from your plugin's | java code to execute your process? | | [snip] | | Thanks | -Vincent | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m 3JIbhwsALTmuwn5OB/7gG9k= =WOfH -END PGP SIGNATURE- - 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]
Working with Branches
Today, for the first time ever, I needed to branch a project in CVS. How do I access that branch with Maven?
Re: Announcements mailing list
Do we want to create/use [EMAIL PROTECTED] in addition? Perhaps to put up plugin releases? Or maybe [EMAIL PROTECTED] since it already exists with its 5 or so subscribers and 1 post :) - Brett On 9/21/05, Trygve Laugstøl [EMAIL PROTECTED] wrote: On Tue, 2005-09-20 at 10:52 -0700, Richard Wallace wrote: Jason van Zyl wrote: We use the announce@apache.org for this. It's relatively low traffic, but we probably won't create an announcement list specifically for Maven itself. Ah I see. Didn't know that. Should probably be mentioned on the mailing lists page for people like me. Guess I'll go subscribe to that one. Done, thanks. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] site:deploy password
Please file a JIRA request for the command line entry, that should be possible now. Mostly we use private keys without a passphrase for this at the moment. I'm not aware of why it might be hanging. Can you scp the file to the remote server outside of Maven? Does the ssh server logs show anything of assistance? - Brett On 9/21/05, Ashley Williams [EMAIL PROTECTED] wrote: Is there some way of specifying the ssh password from the command line as I really don't want to embed it in my settings.xml file. I would much rather enter it every time - I'm referring to this section: server idtomcat/id usernameashley/username password/password /server Additionally does anyone know why site:deploy might hang? It's been sitting there for five minutes now with this output: [INFO] [site:deploy] Executing command: mkdir -p /Applications/tomcat/webapps/projects/ master/essential Executing command: mkdir -p /Applications/tomcat/webapps/projects/ master/essential/ Executing command: scp -t /Applications/tomcat/webapps/projects/ master/essential/site22199.zip Presumably I provided all the credentials successfully or the mkdir commands wouldn't have executed properly. Thanks -AW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] faulty scp protocol handling in wagon?
I have experienced this too - there is an open bug I believe. I'm not sure if the problem is in jsch, or our use of jsch though. I'd welcome any assistance you can provide. Thanks, Brett On 9/21/05, Orjan Austvold [EMAIL PROTECTED] wrote: Often when downloading new artifacts from a scp repository the build fails with Root error: session is down It could be that my the ssh configuration on the scp repository is faulty, but I thought I'd check here before digging into ssh-debugging. In my pom.xml I have configured repositories repository idsecure-repository/id urlscp:/myhost.com/var/mavenrep/maven2/url layoutdefault/layout snapshotPolicydaily/snapshotPolicy /repository repository idcentral/id urlhttp://ibiblio.org/maven2/url /repository /repositories In my settings.xml I have configured settings servers server idsecure-repository/id usernameme/username privateKey/home/me/.ssh/id_dsa/privateKey passphrasemyPassPhrase/passphrase /server /servers mirrors mirror idcloser-central/id urlhttp://mirrors.sunsite.dk/maven2/url layoutdefault/layout snapshotPolicydaily/snapshotPolicy mirrorOfcentral/mirrorOf /mirror /mirrors /settings Best regards, Ørjan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Working with Branches
In Maven 1 properties: maven.scm.tag=BRANCH_TAG_NAME See: http://maven.apache.org/reference/plugins/scm/properties.html In Maven 2 POM: scm ... tagBRANCH_TAG_NAME/tag ... /scm See: http://maven.apache.org/maven2/maven-model/maven.html#class_Scm I haven't used Maven 2 myself yet, but that's what the docs say. Jay -Original Message- From: Jon Strayer [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 20, 2005 2:32 PM To: Maven Users List Subject: Working with Branches Today, for the first time ever, I needed to branch a project in CVS. How do I access that branch with Maven? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Extending Eclipse plugin
Hi Kenney, My comments inline... Kenney Westerhof wrote: On Tue, 20 Sep 2005, Rinku wrote: Hi, I have a use case where I need to reuse/extend the functionality provided by existing M2 Eclipse plugin. The use case involves creating deployables directory from defined project properties and some other updates to .wtpmodules contents. What I want to do is to create sort of a wrapper plugin that can delegate 'standard' goals to the Eclipse plugin and do some pre/post processing around these 'standard' goals. Could anyone please explain what would be a neat way to achieve this and keep the option of being able to reuse future Eclipse plugin releases but just updating the version numbers in pom. I think it would be better if your changes are put in the eclipse plugin (at least for the contents of the .wtpmodules). Creation of custom directories on the other hand is not something the eclipse plugin should do - the maven build should create those too as it needs it.. maybe just use a target/... directory for that and let eclipse automatically create it, like target/classes? Yes, I thought about putting my changes into the existing plugin but then I can't simply reuse any future versions of the Eclipse plugin. Agreed that creation of custom directories is not something that Eclipse plugin should do by default, hence motivation behind creation of wrapper plugin that can handle my project specific properties and delegate them to Eclipse plugin to get the common/standard stuff done. What are the exact changes? Do you think they are general enough to be added to the eclipse plugin? For instance, I need to be able to: a) create additional wb-resource definitions such that I can overlay resource patches for my development environment as per project properties. b) setup wb-module definitions and a context path from my project properties for my application server for use from within Eclipse IDE. I'd prefer to use Eclipse plugin to get the work done to the extent possible and handle only bits that are driven by custom project properties. Appreciate any thoughts, suggestions. Cheers, Rahul . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] reasons for sticking with maven
Ugh, what a long thread to wake up to when you've got a headache :) I think there have been some very good answers here already, but I'll add my own thoughts for completeness. On 9/20/05, Ashley Williams [EMAIL PROTECTED] wrote: Sincere apologies to the dev team if this email seems like a troll, I absolutely don't mean it to be. I'm aware that they continue to do outstanding work and are few in number. Thanks, much appreciated. Constructive criticism is always welcome :) 1. Usability from Ant - there are hundreds of Ant targets out there that are useful for me today. I can't justify waiting for them to be rewritten as Maven equivalents not only because I need functionality today, but also because I don't see why I have to abandon my experience with ant. So far we've only addressed usability OF Ant. You can run ant scripts at phases of the lifecycle using antrun, you can write java plugins that use the Ant API, and Chris and John are putting together Ant plugins. You can already sort of do this with Marmalade (at least that was the intent). The key is that you still get the reusable infrastructure that Maven provides which is what we view as the most important feature of Maven (yes, its not dependency management!) Funnily enough, before I logged in this morning, I was pondering starting the long overdue discussion with the Ant team on how we can best work together to move forward. Ant and Maven are completely different applications, but they could share a lot of code at the task/plugin level. As Jason said, we've been working to do this in the form of common libraries as they are also usable outside of both Ant and Maven, and it'd be good to get a shared direction happening there. Using Maven from Ant? I'm not sure if that is what you meant, but that would be possible too and there is an open JIRA. So far, just dependency management is available. 2. Usability from Eclipse - when will I be able to ditch the command line and create and manage projects entirely from eclipse I'm really surprised this is #2, but as others have pointed out its high on our list too. But we need to finish Maven first, then work on integration. 3. Need to do a myriad of simple things such as automatically run java command or deploy to tomcat. I used to do this all the time in my ant scripts, ie run my build.xml script and at the end it would run my app on completion. It's a credit to those on this list who reply with ideas and workarounds - however this is kind of related to 2 above, where there are lots of ant tasks out there that are tested to death and that I should be able to use today. Are you sure they are tested to death? :) But as stated in 1), you should be able to do this just fine. The important thing is that you are encouraged to spend the small amount of time making it reusable for other projects of your own, and hopefully if something comprehensive is put together then it is shared with all Maven users. 4. Online documentation. Simple example was trying to get the assembly plugin to work which Daniel Shomer had to look into the source code to advise me of what to do. This is just one example of many. Yep, we're working on it. I don't think the emphasis should be on javadocs (With the exception of the plugins, where that is what generates the plugin reference). Short howtos are the approach we are taking for the Maven doco itself. Contributions are welcome, there is a wanted list on the web site. 5. Other project structures. Sometimes I will encounter a project where all the source code is in one tree (beginning with com/). I'm not saying its any better than one directory per artifact, but I am saying I encounter such projects in my career and as such I know I wouldn't be able to use maven. Oh well, its not a silver bullet. There are probably a lot of other things you can't do with that structured project, and maybe you don't need to. If at some point the benefits of restructuring and using Maven outweigh the costs, then go for it - in the mean time, use whatever is already there. There's no way this would make it to #5 on my wish list :) 6. Contribute to the code. I have tried to get a foot in the door in order to fix some of my own critisisms, but the lack of javadocs mean that I really can't do this other than for some simple plugins. That is unless I had lots of time to spare which I don't. In turn that makes me concerned how the project will attract other developers to move things along quickly. Yes, we're working on that too. We've had several new contributors, but there are some barriers to entry. Specific pointers to things that are too hard are good. Now I'll turn my attention to Ivy. I've began to look at this product and it seems to offer many of the features of Maven including 1. transitive dependencies many != 1 :) As Jason said, apples and oranges. Ivy is a very good dependency manager. So is Maven. Ivy doesn't
Re: [m2] assembly plugin
Ashley Williams wrote: Does anyone know how to use assembly:assembly, in particular what the descriptor is supposed to be? I did hardcode it as a path to my pom from within my pom (that seems wrong) which made the plugin run without errors, but I didn't see any output file. Thanks -AW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ashley, You could create your own Descriptor file. Here is the example of descriptor that was used when you run m2 assembly:assembly -DdescriptorId=jar-with-dependencies. assembly idjar-with-dependencies/id formats formatjar/format /formats includeBaseDirectoryfalse/includeBaseDirectory fileSets fileSet directorytarget/classes/directory outputDirectory//outputDirectory /fileSet /fileSets dependencySets dependencySet outputDirectory//outputDirectory unpacktrue/unpack scoperuntime/scope /dependencySet /dependencySets /assembly You could create your own descriptor to get what you want. To use your customized descriptor file, use m2 assembly:assembly -Ddescriptor=path/to/your/descriptor.xml. Hope this helps, --- Johnny :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: .cvspass file not found on windows.
the .cvspass file ought to be created when you do a cvs login there are a host of issues that can crop up with this on a windows box though..least of which is where the file is created.. I would make sure that you set a HOME environment variable and make sure you see it set in the shell that you run the cvs login from...then the .cvspass file will be generated in that directory. the cvs documentation shows a number of the pitfalls that can crop up with this process. a general rule of thumb is that if you can execute the cvs commands in a cmd prompt without authentication issues when maven-scm and continuum things shouldn't have a problem. jesse On 9/20/05, Mick Knutson [EMAIL PROTECTED] wrote: I am trying to setup scm in maven, and I am using wincvs to access my cvs server. I have searched, and do not find a .cvspass file and maven is also complaining about this. How do I fix this issue? Create a .cvspas file? How with WinCvs? Thank You Mick Knutson Sr. Java/J2EE Consultant BASE logic, inc. (415) 648-1804 (S.F., CA) http://www.BASELogic.com HP Consulting Services (Walnut Creek, CA) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell
Re: .cvspass file not found on windows.
Try running: changelog:create-cvspass Hope it helps Eric. Mick Knutson wrote: I am trying to setup scm in maven, and I am using wincvs to access my cvs server. I have searched, and do not find a .cvspass file and maven is also complaining about this. How do I fix this issue? Create a .cvspas file? How with WinCvs? Thank You Mick Knutson Sr. Java/J2EE Consultant BASE logic, inc. (415) 648-1804 (S.F., CA) http://www.BASELogic.com HP Consulting Services (Walnut Creek, CA) - 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]
