xdoclet plugin : Jboss
I've been using the xdoclet plugin and have put the following into the maven directories repository/xdoclet/jars/ xdoclet-1.2b4.jar xdoclet-ejb-module-1.2b4.jar xdoclet-jboss-module-1.2b4.jar xdoclet-jmx-module-1.2b4.jar xdoclet-xdoclet-module-1.2b4.jar xdoclet-xjavadoc-1.0.jar plugins/ maven-xdoclet-plugin-1.2b4.jar maven-xdoclet-plugin-1.2b4/... I have defined a preGoal xdoclet:ejbdoclet in maven.xml If I run this with just the following dependencies dependency idxdoclet/id version1.2b4/version /dependency dependency idxdoclet+ejb-module/id version1.2b4/version /dependency dependency idj2ee/id version1.3.1/version /dependency the ejbdoclet task runs fine, creating the ejb-jar.xml and required interfaces. However if I add the necessary dependencies (from xdoclet website description) to run the JBoss part dependency idxdoclet+jboss-module/id version1.2b4/version /dependency dependency idxdoclet+jmx-module/id version1.2b4/version /dependency maven just skips past the preGoal doing nothing (not even the ejb-jar.xml/interfaces part). Anyone used xdoclet to generate JBoss descriptors with the Maven plugin? TIA -- Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2EE project : EAR/WAR/JAR - web site generation
Andy, Where did you find the J2EE maven articles? I'm very interested in seeing how J2EE and maven work together and have the same project granularity issues as you. Perhaps we can help each other. Aaron From: Andy Jefferson [EMAIL PROTECTED] Reply-To: Maven Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: J2EE project : EAR/WAR/JAR - web site generation Date: 12 Jul 2003 21:47:25 +0100 I have a J2EE project, and currently have things under one Maven project. I have been building with Ant, but want to swap to Maven for more than just project management and site generation. Reading of various articles suggests that I split the current project as follows Top level project - depends on JAR, WAR, builds EAR Child bean project- builds JAR Child web-app project - depends on JAR, builds WAR So I set up project.xml for each, and I already have template project.xml files set up. For a normal project, I get web site docs with a navigation section Project Documentation. What would I get for the resultant project by splitting into the above hierarchy ? Would there be 3 sections of 'Project Documentation' for beans, web-app, and overall ? Or would I have to put up 3 web sites and make my own links between them ? Thx -- Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: J2EE project : EAR/WAR/JAR - web site generation
Hi Aaron, I have presented a talk at TheServerSide Symposium about building J2EE applications with Maven. You can find the slides there: http://blogs.codehaus.org/people/vmassol/archives/80.html Thanks -Vincent -Original Message- From: Aaron Robinson [mailto:[EMAIL PROTECTED] Sent: 13 July 2003 12:04 To: [EMAIL PROTECTED] Subject: Re: J2EE project : EAR/WAR/JAR - web site generation Andy, Where did you find the J2EE maven articles? I'm very interested in seeing how J2EE and maven work together and have the same project granularity issues as you. Perhaps we can help each other. Aaron From: Andy Jefferson [EMAIL PROTECTED] Reply-To: Maven Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: J2EE project : EAR/WAR/JAR - web site generation Date: 12 Jul 2003 21:47:25 +0100 I have a J2EE project, and currently have things under one Maven project. I have been building with Ant, but want to swap to Maven for more than just project management and site generation. Reading of various articles suggests that I split the current project as follows Top level project - depends on JAR, WAR, builds EAR Child bean project- builds JAR Child web-app project - depends on JAR, builds WAR So I set up project.xml for each, and I already have template project.xml files set up. For a normal project, I get web site docs with a navigation section Project Documentation. What would I get for the resultant project by splitting into the above hierarchy ? Would there be 3 sections of 'Project Documentation' for beans, web-app, and overall ? Or would I have to put up 3 web sites and make my own links between them ? Thx -- Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile - 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: Keeping your test source code in a separate, but parallel source tree
On Saturday, July 12, 2003, at 08:02 PM, Dave Ford wrote: The advantage I see is that you get to have test code that has package-level access Actually, you get that by placing them in the same directory also. So that's not really an advantage. and because it's in a separate tree, it's easy to build binaries that don't include all the test code... Obviously, this is easily accomplished by tools such as Ant or Maven by simply excluding *Test That assumes that your test code is so simple that everything fits a pattern like that. If so, yes, your are right. But when there's other code that isn't *Test, then it helps to be able to have a separate tree geir So, back to my question. Why is this a best practice? Maybe it's a common practices, possibly a standard practiced, but no one has yet convinced me it's best practice. Dave Ford Smart Soft - The Developer Training Company http://www.smart-soft.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: J2EE project : EAR/WAR/JAR - web site generation
Vincent, FYI, the link appears to be down: - The requested URL /pdf/Unit_Testing_J2EE_V1.1.pdf was not found on this server Cheers Aaron From: Vincent Massol [EMAIL PROTECTED] Reply-To: Maven Users List [EMAIL PROTECTED] To: 'Maven Users List' [EMAIL PROTECTED] Subject: RE: J2EE project : EAR/WAR/JAR - web site generation Date: Sun, 13 Jul 2003 12:28:40 +0200 Hi Aaron, I have presented a talk at TheServerSide Symposium about building J2EE applications with Maven. You can find the slides there: http://blogs.codehaus.org/people/vmassol/archives/80.html Thanks -Vincent -Original Message- From: Aaron Robinson [mailto:[EMAIL PROTECTED] Sent: 13 July 2003 12:04 To: [EMAIL PROTECTED] Subject: Re: J2EE project : EAR/WAR/JAR - web site generation Andy, Where did you find the J2EE maven articles? I'm very interested in seeing how J2EE and maven work together and have the same project granularity issues as you. Perhaps we can help each other. Aaron From: Andy Jefferson [EMAIL PROTECTED] Reply-To: Maven Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: J2EE project : EAR/WAR/JAR - web site generation Date: 12 Jul 2003 21:47:25 +0100 I have a J2EE project, and currently have things under one Maven project. I have been building with Ant, but want to swap to Maven for more than just project management and site generation. Reading of various articles suggests that I split the current project as follows Top level project - depends on JAR, WAR, builds EAR Child bean project- builds JAR Child web-app project - depends on JAR, builds WAR So I set up project.xml for each, and I already have template project.xml files set up. For a normal project, I get web site docs with a navigation section Project Documentation. What would I get for the resultant project by splitting into the above hierarchy ? Would there be 3 sections of 'Project Documentation' for beans, web-app, and overall ? Or would I have to put up 3 web sites and make my own links between them ? Thx -- Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile - 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] _ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: J2EE project : EAR/WAR/JAR - web site generation
Arg! You're right, we are internationalizing our web site and the webmaster has mixed up things. You can find them here: http://www.pivolis.com/fr/pdf/J2EE_projects_Maven_V1.1.pdf Sorry about that. I've asked him to restore the old link. -Vincent -Original Message- From: Aaron Robinson [mailto:[EMAIL PROTECTED] Sent: 13 July 2003 12:46 To: [EMAIL PROTECTED] Subject: RE: J2EE project : EAR/WAR/JAR - web site generation Vincent, FYI, the link appears to be down: - The requested URL /pdf/Unit_Testing_J2EE_V1.1.pdf was not found on this server Cheers Aaron From: Vincent Massol [EMAIL PROTECTED] Reply-To: Maven Users List [EMAIL PROTECTED] To: 'Maven Users List' [EMAIL PROTECTED] Subject: RE: J2EE project : EAR/WAR/JAR - web site generation Date: Sun, 13 Jul 2003 12:28:40 +0200 Hi Aaron, I have presented a talk at TheServerSide Symposium about building J2EE applications with Maven. You can find the slides there: http://blogs.codehaus.org/people/vmassol/archives/80.html Thanks -Vincent -Original Message- From: Aaron Robinson [mailto:[EMAIL PROTECTED] Sent: 13 July 2003 12:04 To: [EMAIL PROTECTED] Subject: Re: J2EE project : EAR/WAR/JAR - web site generation Andy, Where did you find the J2EE maven articles? I'm very interested in seeing how J2EE and maven work together and have the same project granularity issues as you. Perhaps we can help each other. Aaron From: Andy Jefferson [EMAIL PROTECTED] Reply-To: Maven Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: J2EE project : EAR/WAR/JAR - web site generation Date: 12 Jul 2003 21:47:25 +0100 I have a J2EE project, and currently have things under one Maven project. I have been building with Ant, but want to swap to Maven for more than just project management and site generation. Reading of various articles suggests that I split the current project as follows Top level project - depends on JAR, WAR, builds EAR Child bean project- builds JAR Child web-app project - depends on JAR, builds WAR So I set up project.xml for each, and I already have template project.xml files set up. For a normal project, I get web site docs with a navigation section Project Documentation. What would I get for the resultant project by splitting into the above hierarchy ? Would there be 3 sections of 'Project Documentation' for beans, web-app, and overall ? Or would I have to put up 3 web sites and make my own links between them ? Thx -- Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile - 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] _ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile - 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: J2EE project : EAR/WAR/JAR - web site generation
I've slapped up a page on the wiki for this http://wiki.codehaus.org/maven/OtherMavenArticles#preview (Yes I realise this duplicates a static xdoc page we have, but it's all part of my master plan!) Andy Jefferson wrote: On Sun, 2003-07-13 at 11:04, Aaron Robinson wrote: Andy, Where did you find the J2EE maven articles? I'm very interested in seeing how J2EE and maven work together and have the same project granularity issues as you. Perhaps we can help each other. Hi Aaron, the docs I've been looking at are Incorporation of XDoclet http://xdoclet.sourceforge.net/maven-plugin.html IBM review of Maven and implementation for J2EE http://www-106.ibm.com/developerworks/java/library/j-maven/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping your test source code in a separate, but parallelsourcetree
Thanks Gilles,
Its good to know that this is configurable, I'm working on another
project where we're trying to get Maven working but cannot yet
restructure the cvs to meet assumed Maven best practices without
breaking the old build.
I'd caution on the use of default settings as a rule for what Maven
encourages/discourages. Developers are always going to have varying
requirements. Forcing them into a box will only reduce your user base in
the long run. The current defaults are great if your starting a new
project, they are far from adequate when attempting to Mavenize an
existing project. The Maven team should avoid using defaults as some
sort of inflexible standard.
Note: Much of this argument could be easily avoided if the core maven
properties and capabilities were clearly documented somewhere. Somehow
this documentation is lacking as maven itself is not in the pluggins
documentation and such properties are documented nowhere.
-Mark Diggory
Gilles Dodinet wrote:
Dave, brendan,
Just a quick note about this. it seems that maven actually does allow to
keep all main and test sources under one dir .
just make sourceDirectory and unitTestSourceDirectory point to the same
dir, then your test will be run.
About the artifact generation, when building jar, you just can exclude
your test files files using ${maven.jar.excludes}.
ive just tried it with a dummy example and it seems to work.
its not that im using this layout (i have parallel source trees), so it
might eventually require additional efforts for other artifacts generation.
So i think that maven doesnot strictly forbids the all-in-one-dir
practice, it s more that it just discourages it. tho perhaps im missing
something.
-- gd
Jason van Zyl wrote:
On Sat, 2003-07-12 at 20:14, Bob Cumbers wrote:
Never going to happen and I make no apologies for that.
It's nice to see that you take user input so graciously
Give me a break.
When I think something is categorically a bad practice then the dialog
is cut short. I am not trying to win any popularity contests and I'm
don't care if every single user is happy. It's just not possible. But I
have taken loads of suggestions for Maven and they have found there way
into Maven. But there are several issues like multiple sources
directories, mixing test and application code and several other issues
which I will not change my mind on.
Maven is but one solution for building your project. I encourage anyone
not happy with it to go find something else.
I also take into consideration the number of downloads in constrast with
the number of people who complain about certain limitations. I certainly
don't think mixing test/application code is a good idea but I think
given that I've only seen a few people want this out of the thousands
that have downloaded Maven is a good indicator that most users think
it's not a very good idea. I'm not a politician, I could care less if
all users like me because most users are selfish and only consider their
own methods and own desires when requesting features while generally
never considering larger issues. As always there are the valued and
treasured exceptions by users who have genuinely taken into
consideration all users and the larger issues. Just because a user makes
a suggestion doesn't mean it's a good one. If you're looking for grace
go somewhere else.
-
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
-
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: Keeping your test source code in a separate, but parallelsourcetree
This is all but one opinion on the subject. IMHO, as this is a user list and not a developer list, I'd advise that moderation should not be so restrictive when the subject matter is not at all off topic. I also think that comparing total downloads against any discussion is a very poor and biased measure of user needs/requirements. If you go around cutting discussions short, then your biasing such a measure in favor of your own personal opinion and as such it does not reflect the true opinion of your userbase. -Mark Diggory http://jakarta.apache.org/commons/sandbox/math/index.html Jason van Zyl wrote: On Sat, 2003-07-12 at 20:14, Bob Cumbers wrote: Never going to happen and I make no apologies for that. It's nice to see that you take user input so graciously Give me a break. When I think something is categorically a bad practice then the dialog is cut short. I am not trying to win any popularity contests and I'm don't care if every single user is happy. It's just not possible. But I have taken loads of suggestions for Maven and they have found there way into Maven. But there are several issues like multiple sources directories, mixing test and application code and several other issues which I will not change my mind on. Maven is but one solution for building your project. I encourage anyone not happy with it to go find something else. I also take into consideration the number of downloads in constrast with the number of people who complain about certain limitations. I certainly don't think mixing test/application code is a good idea but I think given that I've only seen a few people want this out of the thousands that have downloaded Maven is a good indicator that most users think it's not a very good idea. I'm not a politician, I could care less if all users like me because most users are selfish and only consider their own methods and own desires when requesting features while generally never considering larger issues. As always there are the valued and treasured exceptions by users who have genuinely taken into consideration all users and the larger issues. Just because a user makes a suggestion doesn't mean it's a good one. If you're looking for grace go somewhere else. - Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jar:deploy and ssh password
Thanks. I thought I need to do something else. It turns out that my public web server only supports an old version of ssh with some strange additional restrictions. Confused the heck out of me. On top of it, I'm an old unix guy chained to a windows box (which confuses me even more). -max -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, July 13, 2003 2:19 PM To: Maven Users List Subject: Re: Jar:deploy and ssh password Under Linux, the destination host of the ssh connection must include an authorized_keys file for connections that do not require an interactive password be entered. See http://www.openssh.org/manual.html. The link for ssh discuss use of the authorized_keys file. Thanks. --- Maximilian A. Ott [EMAIL PROTECTED] wrote: When I run jar:deploy it gets to: jar:jar: [echo] Moving target/sx.util-1.1.3.jar to the . And hangs. From looking at the plug-in code (and a few error messages due to incorrect property settings) I know it calls ssh at this stage. Now, if I run the specific command from the shell it prompts me for the password. This is obviously suppressed here. How can I make that work (Windows, ssh2). Thanks, -max - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.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]
Re: Keeping your test source code in a separate,but parallelsource tree
On Sun, 2003-07-13 at 14:43, Mark R. Diggory wrote: Thanks Gilles, Its good to know that this is configurable, I'm working on another project where we're trying to get Maven working but cannot yet restructure the cvs to meet assumed Maven best practices without breaking the old build. I'd caution on the use of default settings as a rule for what Maven encourages/discourages. Developers are always going to have varying requirements. That will always be true but why do we as developers demand consistent APIs for everything we use and then ignore this rule when constructing build systems? What is good about having N different ways a build system works? And if you disagree you have plenty of tools to choose from. Forcing them into a box will only reduce your user base in the long run. Much to my dismay this has not been the case. And the target for me has always been newer users because anyone with an existing build has always tried to demand to have their way incorporated as an option in Maven. It has always been the intent to strive for consistency and coherence, sometimes at the cost of other things. That was a conscious decision. The current defaults are great if your starting a new project, they are far from adequate when attempting to Mavenize an existing project. There has never been an attempt to accommodate the myriad ways of doing things. Maven is not Ant. The Maven team should avoid using defaults as some sort of inflexible standard. The whole point of Maven is to provide some uniformity and coherence from the ground up. Lots of people don't like the way Maven works and that's perfectly fine. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xdoclet plugin : Jboss
On Sun, 2003-07-13 at 16:30, [EMAIL PROTECTED] wrote: Make sure you include the xjavadoc dependency. I have: artifactIdcommons-jelly-tags-log/artifactId version20030211.142821/version artifactIdcommons-jelly-tags-interaction/artifactId versionSNAPSHOT/version artifactIdxdoclet/artifactId version1.2b4/version artifactIdxdoclet-xdoclet-module/artifactId version1.2b4/version artifactIdxjavadoc/artifactId version1.0/version artifactIdxdoclet-jdo-module/artifactId version1.2b4/version artifactIdxdoclet-ejb-module/artifactId version1.2b4/version artifactIdxdoclet-web-module/artifactId version1.2b4/version artifactIdxdoclet-jboss-module/artifactId version1.2b4/version artifactIdxdoclet-apache-module/artifactId version1.2b4/version artifactIdxdoclet-jmx-module/artifactId version1.2b4/version Hi, I've tried using all of the above (except the commons-jelly ones, and the xdoclet-jdo, xdoclet-apache - since I'm not using any of those), and I still get no success. If I comment out just the xdoclet-jboss-module, it runs through xdoclet fine (for the ejb tags). If I uncomment it, I get java:compile: [mkdir] Created dir: /home/andy/work/WebShop/target/xdoclet xdoclet:ejbdoclet: [javac] Since fork is true, ignoring compiler setting. [javac] Compiling 80 source files to /home/andy/work/WebShop/target/classes [javac] Since fork is true, ignoring compiler setting. and it ignores the work its supposed to do in ejbdoclet (!). -- Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xdoclet plugin : Jboss
On Sun, 2003-07-13 at 21:30, Andy Jefferson wrote: I've tried using all of the above (except the commons-jelly ones, and the xdoclet-jdo, xdoclet-apache - since I'm not using any of those), and I still get no success. It appears that I lied :-) ... turns out that I was missing the xdoclet-web-module and without that it doesn't bother giving an error or anything. Include it and it works fine ! -- Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does one register a plug-in?
Make sure you delete the *.cache files. Dave Ford wrote: I just copied one the plug-ins from the plug-ins folder and used it to create my own plug-in. when I go to run it, Maven tells me that the plug-in does not exist in this project. Do I have to register the plug-in somewhere? Dave Ford Smart Soft - The Developer Training Company http://www.smart-soft.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]
Re: Keeping your test source code in a separate,but parallelsource tree
in the long run it will be better to sacrifice some variability for a standard, even if some of the standard is ad hoc. That's a good point Jason. Dave Ford Smart Soft - The Developer Training Company http://www.smart-soft.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
b10
Howdy, A few people have tried the test installers so I'll let it sit over night and release it tomorrow. If anyone happens to want to try the installers they are here: http://www.apache.org/~jvanzyl -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
