Thanks for the heads up.
Quite timely, in fact. As a newcomer to JBoss CVS RW (just got added a few hrs ago), I'm wading thru the tons of docs on Sourceforge, and thinking about how it maps to Eclipse. It shouldnt be too tough just to check in a module update, but I'm the kind of guy who likes to figure it all out (and understand more than the specific piece I need) ... before hacking around and maybe making a mess.
I'm guessing these are the right cmds (incorporating your hostname news) if I were to be using a shell...
export CVS_RSH=ssh cvs -firstname.lastname@example.org:/cvsroot/jboss login cvs -z3 -email@example.com:/cvsroot/jboss co nukes cvs -z3 update -Pd cvs -z3 ci
...but maybe I'm missing something important, and I still dont know what gotchas there might be with doing this from the combination of Eclipse and SecureCRT (my SSH client... I dont even know whether Eclipse has its own SSH client ?, or if it has to go out to mySecureCRT ?)
A quick step by step, specifically for the JBoss/Nukes - Sourceforge - Eclipse combination, would be most appreciated. (including how to make sure that only the module that I wish to update is updated (even if I've modified other modules locally), how to avoid overwrites from the server of any of my local changes that are not in CVS yet, and eliminate risk of screwing anything up in CVS outside of the specific files I wish to commit.)
Once again, wading thru tons of docs all over the web... about the quirks of working with CVS and SSH in the context of Sourceforge and Eclipse ... and then it turns out to be really easy....
Practicing what I'm preaching, I'll throw out some breadcrumbs for those who come later:
* Login at Sourceforge and read the "Introduction to SourceForge.net Project CVS Services for Developers" even tho only 10% is relevant.
* You can use any SSH client to log in to Sourceforge first time to create a home dir; you dont have to use the same SSH client that you will later use to do checkouts, updates, and commits.
If xxxxx is your sourceforge user id...
ssh -l xxxxx cvs.sourceforge.net
You'll see something like this:
The authenticity of host 'cvs.sourceforge.net (188.8.131.52)' can't be established. DSA key fingerprint is 02:ab:7c:aa:49:ed:0b:a8:50:13:10:c2:3e:92:0f:42. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'cvs.sourceforge.net,184.108.40.206' (DSA) to the list of known hosts. firstname.lastname@example.org's password: Creating directory '/home/users/x/xx/xxxxx'. Welcome to cvs1.sourceforge.net This is a restricted Shell Account You cannot execute anything here. Connection to cvs.sourceforge.net closed.
* For checkouts, updates, and commits, use extssh in Eclipse. Built-in SSH client, no need to screw with encryption key generation, nice.
* Almost the same as anonymous (pserver) checkouts into Eclipse:
Open the CVS Repository Explorer (Window > Open Perspective > Other > CVS Repository Exploring)
Create a new Repository Location using the right context menu.
Specify the hostname as cvs.sourceforge.net
the repository path as /cvsroot/jboss
As a registered developer you can use connection type extssh and your sourceforge user-id and password.
Open "Head" in the "/cvsroot/jboss" repository, and choose "nukes" with a right-click and select "Check out".
When you want to to commit, right click in the tree on the lowest level node that contains the files you want to commit, then to the Team submenu, then Commit...
Yup, even tho theres no decent doco, the actual Eclipse/Sourceforge combo indeed doesnt suck.
it does work w/ "ext" as well (this is the method i use). but requires more work b/c you need to setup your paths, etc outside of eclipse, and you also need a command line version of ssh available.
it also allows you to use ssh2, which is not currently avail in eclipse 2.x w/o an additional plugin (it is part of 3.0 tho).
key generation is nice b/c it alleviates the need to constantly type in your password, which i find to be quite annoying after a while.
version 3.0 has a nice synchronization perspective (dunno if 2.x has it, and if it did, i never used it) that makes it really easy to commit changes and avoid checking in code that shouldn't be.
i'm quite familiar w/ most of this b/c i use it at work and for nukes development, so let me know if you have any questions.
Thanks for these good CVS/Eclipse tips -- I'll try em out when I set up for my next cycle.
For now, trying to wrapup this cycle... right now, is CVS in a consistent state? Builds are ok on both my envirs, but there seem to be probs in the installer phase.... datasource issues?, possibly related to how hsqldb value in local.properties isnt being propagated fully?
Also, how is "@nukes.news" interpreted, what does it control? (I blindly put "@nukes.faq" in mine, without researching all about it, like I normally would.)
I gotta run out & do other stuff for awhile, but a test & reply to my last post over on "MySQL & Pure-CMP --- issues w News & FAQ modules" would be most helpful.
the @nukes.news is used via the build. i've hooked up the news database tables to reference the "core" user tables, etc and by doing that, i need to include deployment descriptor information.
if you look at the build.xml in the xdoclet section, it states that only interfaces should be generated for files that have the @nukes.news tag in them. this allows me to generate my interfaces and include the necessary info for the "core" ejbs in my deployment descriptors.
i'll try and take a look at the other stuff over the weekend and see if i can figure out what's going on.
I'm trying to check nukes out as a java project, or is there another way to get Eclipse's full java functionality on a project? Ok, I'm aware that I can't use eclipse to build, but I's like to use "External tools" to accomplish the call to build.(bat|sh).
What I'm stumbling over is:
Class org.jboss.nukes.handler.NukesImpl inherits from ServletRequest / ServletResponse but doesn't implement the abstract methods required.
Is there magic in play, because apparently the build script is able to compile it... the compiler should moan if a non-abstract class doesn't implement all declared abstract methods, shouldn't it?
You can check the Nukes moduke out into an Eclipse Java project.
In Eclipse 3.0 M8, you can run an Ant build on Nukes without using the build.sh/build.bat.
What version of Nukes are you looking at? Here is the signature I have:
public class NukesImpl implements NukesRequest, NukesResponse
This has compiled fine in my Eclipse environment.
compiling resp. building is not my problem, I just call the build.bat as ExternalTask.
The (future) problem is (sorry I didn't check before I posted :-)
/** * @author <a href="mailto:email@example.com">Julien Viet</a> * @version $Revision: 1.7 $ */ public class NukesImpl implements NukesRequest, NukesResponse
inherits from NukesRequest:
/** * Extends HttpServletRequest capabilities. * * @author <a href="mailto:firstname.lastname@example.org">Julien Viet</a> * @version $Revision: 1.13 $ */ public interface NukesRequest extends HttpServletRequest
HttpServletRequest resp. ServletRequest has got abstract methods in J2EE 1.4.2:
abstract ServletRequest.getLocalAddr(); abstract ServletRequest.getLocalName(); abstract ServletRequest.getLocalPort(); abstract ServletRequest.getRemotePort();
which are not implemented yet. That's all of my problem :-)
Thank you for your quick response!
Nukes only works against JBoss 3.2.3, which is J2EE 1.3. Haven't tried it against 3.2.4, which is at RC1 right now.
Where does J2EE 1.4.2 come in?
let's wait 3.2.4 final to switch
The background is, that I'm currently porting a php shop to java. I'm thinking about implementing it as nukes module and trying to get on speed with nukes at the moment, so please forgive me if I need some time to get familiar with it and ask silly questions. (Currently it is a struts/tiles/CMP approach)
J2EE 1.4.2 has come into play in my local dev-environment... I'd choosen to take the latest when developing new stuff.
So sorry to bother.