incubator-imperius-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Wood <daw...@us.ibm.com>
Subject Re: IDE support in the repository
Date Tue, 02 Sep 2008 14:20:56 GMT
Ok, it turns out it's fairly straightforward to create an Eclipse project 
that links to the source in the Imperius trunk.  It's very small, just a 
.classpath and a .project file.  My hope would be that after using SVN to 
check out the trunk, one uses Eclipse SVN plugin to checkout this project 
and low and behold you're up and running in Eclipse editing the linked 
source.  I've only done this for the core code (imperius-splcore and 
imperius-javaspl), and we may want to have a separate project for the 
Eclipse editor plugin.

Now, there is a maven plugin for Eclipse also,  so perhaps there is an 
alternative to this approach, but this is so simple and quick to get folks 
up an running (i.e. no plugin install required). 

What does everyone think? 

David Wood 
Network Server System Software Group
IBM TJ Watson Research Center
dawood@us.ibm.com
914-784-5123 (office), 914-396-6515 (mobile)




From:
David Wood/Watson/IBM@IBMUS
To:
imperius-dev@incubator.apache.org
Date:
09/01/2008 07:08 PM
Subject:
Re: IDE support in the repository



I'm not sure why we need to put things in a separate place as long as they 

don't disrupt the existing processes.  However, all I'm really after is to 

be able to 'import' or otherwise include the Imperius code into an Eclipse 

workspace.  If we can figure out a way to do that an have the files 
elsewhere, that is fine with me, although I think these need to be 
included in the SVN tree and not maintained separately.  These IDE files 
will likely need to evolve with the code, so keeping them separate outside 

of SVN begs for trouble.  If this is agreeable, then perhaps something 
along the lines of trunk/ide/{eclipse,netbeans} with a parallel structure 
to the source tree.  These directories could then include (for example) 
imperius-splcore/.project file that reference the source at 
trunk/imperius-splcore.  What do you think?

David Wood 
Network Server System Software Group
IBM TJ Watson Research Center
dawood@us.ibm.com
914-784-5123 (office), 914-396-6515 (mobile)




From:
Neeraj Joshi/Durham/IBM@IBMUS
To:
imperius-dev@incubator.apache.org
Date:
09/01/2008 09:21 AM
Subject:
Re: IDE support in the repository



I suggest we upload the the eclipse specific files in a zip format and 
make it available via the website (perhaps the development section) that 
way 
the SVN is still unbiased and the developers have easy access to the 
project information. What do you guys think?

Thanks
Neeraj
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The light at the end of the tunnel...may be you"

 
Neeraj Joshi
WebSphere XD - Compute Grid
AIM, IBM
Apache Imperius - http://incubator.apache.org/imperius
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



David Wood/Watson/IBM@IBMUS 
08/29/2008 10:37 AM
Please respond to
imperius-dev@incubator.apache.org


To
imperius-dev@incubator.apache.org
cc

Subject
IDE support in the repository






I suspect all of us are using some sort of IDE to develop.  With this in 
mind, I think it would help us all be more productive if we can find a way 



to include support for the IDEs in the SVN repository?  I'm using Eclipse, 



but  wouldn't want to push that on anyone and hope we could support 
multiple IDEs.  In the case of Eclipse, I think it may be as simple as 
building a .project and .classpath file into the right directory.  I've 
had success in creating two projects for the imperius-splcore and 
imperius-javaspl directories.  I don't believe these files would otherwise 



disrupt the existing build/development process, but correct me if I'm 
wrong.  Does this strategy work for other IDEs?  Do people have another 
suggestion for how we might accomplish IDE support?  How to proceed?

David Wood 
Network Server System Software Group
IBM TJ Watson Research Center
dawood@us.ibm.com
914-784-5123 (office), 914-396-6515 (mobile)







Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message