jrmtool-developers — Developers on the Eclipse Reflexion Model plug-in

[jrmtool-developers] New plugin

[Jacek R. <pa...@fa...>]

Hi All,

I have just uploaded new plug-in at:
http://svn.sourceforge.net/svnroot/jrmtool/trunk/net.sf.jrmtool

This contains merged changes by both Rory and Jonathan.

As we agreed earlier I have changed the name to 'net.sf.jrmtool'. I
decided to reset plug-in version to, as this will reflect that it is
currently unstable and it seamed feasible to me as the name has changed.

I have deliberately left out '.project' and '.classpath' files. Those
files were causing some minor problems in the past and in my opinion
should not be in the repository. So if You want to check out the project
now you need to use 'check out with new project wizard' option when
checking out.

I have also left out documentation. It's currently a bit out of date and
in my opinion it can be maintained as a separate project (under
different directory). When we update it we can either re-add it or put
it in a new project. This does not concern readme and license files,
which I will later re-add after updating.

I have changed copyright notice on all files. On files created by Rory,
Jonathan or me i used UL copyright and I have left old copyright notice
on other files. I changed the license on all files though, which is EPL
now. I left contributors as it was, only added new contributors where
applicable. I hope this is ok, you may want to briefly check those
changes as I may have made some mistakes.

Known bugs:
* saved reflexion model does not contain front-end changes
* saved reflexion model does not work under linux or macosx
* plug-in will crash when run against itself, not sure yet but I think
it's eclipse limitation

That's about it, enjoy!

Regards,
-- 
Jacek Rosik <pa...@fa...>

RE: [jrmtool-developers] Copyrights, renaming, etc.

[Gail M. <mu...@cs...>]

Sounds good. Only use the UBC copyright on those we did create (obviously).
Otherwise, appropriate name should be substituted.

Here's Martin's response about moving Javadb in. We need to set it up so it
can be separately checked-in and checked-out and give him rights (I can do
that). It should stay as the package naming scheme it has. Would you like to
move it in?

> Assuming the above is not a problem, it's a go!  If someone is willing 
> to move the code from my website to the sourceforge site, change the 
> license, and give me access rights, I'm OK with that.  I'll re-link my 
> website once the changeover is complete. 

Gail.

> -----Original Message-----
> From: jrm...@li... 
> [mailto:jrm...@li...] On 
> Behalf Of Jacek Rosik
> Sent: May 15, 2006 5:08 AM
> To: mu...@cs...
> Cc: 'jRMTool Developers List'
> Subject: Re: [jrmtool-developers] Copyrights, renaming, etc.
> 
> Hi,
> 
> I have just merged front-end changes into the trunk. I think 
> we can go ahead with proposed changes as I wouldn't worry 
> about back-end changes branch as I will probably recreate it 
> after we apply those changes.
> 
> I can do the first two changes. 
> 
> For the first one I think I can do it semi-automatically so I 
> don't need to edit each file.
> 
> As for the package name change I would like to do it manually 
> from command line. This will make sure that we preserve all 
> the history as directory renames can be tricky and I don't 
> trust Subclipse that much ;)
> 
> Just to clarify.
> 
> New package root: net.sf.jrmtool
> New plug-in id: net.sf.jrmtool
> New file header:
> /*************************************************************
> ******************
>  * Copyright (c) 2004 - 2006 University Of British Columbia 
> and others.
>  * All rights reserved. This program and the accompanying materials
>  * are made available under the terms of the Eclipse Public 
> License v1.0
>  * which accompanies this distribution, and is available at
>  * http://www.eclipse.org/legal/epl-v10.html
>  *
>  * Contributors:
>  *     University Of British Columbia - initial API and implementation
>  
> **************************************************************
> *****************/
> 
> 
> So If you don't mind I'm willing to do this changes asap.
> 
> Has Martin Robillard agreed to import javadb sources into our 
> repository?
> 
> 
> On Tue, 2006-04-25 at 16:29 -0700, Gail Murphy wrote:
> > Hi,
> >  
> > I'd like to propose the following changes which I'm willing to do 
> > (coordinate in the case of one):
> >       * Change all copyrights to EPL of the form below 
> unless it was a
> >         class added by others in which case it should be accurate in
> >         the top line, last line:
> > 
> /*********************************************************************
> > **********
> >  * Copyright (c) 2004 - 2006 University Of British Columbia and 
> > others.
> >  * All rights reserved. This program and the accompanying materials
> >  * are made available under the terms of the Eclipse Public License 
> > v1.0
> >  * which accompanies this distribution, and is available at
> >  * http://www.eclipse.org/legal/epl-v10.html
> >  *
> >  * Contributors:
> >  *     University Of British Columbia - initial API and 
> implementation
> >  
> > 
> **********************************************************************
> > *********/
> >  
> >       * Switch to a net.sf.jrmtool (etc.) package naming to reflect
> >         the fact that others are working on the code.
> >       * Add a net.sf.jrmtool.test package for junit tests of
> >         non-Eclipse parts of the system
> >       * Add a net.sf.jrmtool.eclipse.test package for Eclipse-based
> >         tests (perhaps non-automated tests for now)
> >  
> > I am emailing with Martin Robillard (creator of FEAT) about 
> creating a 
> > separate entry under trunk: trunk/feat (if that's feasible) to 
> > incorporate the FEAT code under EPL. Hopefully we'll have 
> an update on 
> > that available soon.
> >  
> > What is the process we are using on creating branches and doing 
> > merges? I'm reluctant to have too many branches outstanding 
> (but maybe 
> > that's because I'm a naive subversion user). For instance, it seems 
> > like at least the front-end improvements (if they are 
> working) should 
> > be merged to trunk before I create a branch to do the 
> copyright change 
> > or renaming.
> >  
> > Gail.
> >  
> >  
> --
> Jacek Rosik <jac...@ul...>
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web 
> services, security?
> Get stuff done quickly with pre-integrated technology to make 
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on 
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&
> dat=121642
> _______________________________________________
> jrmtool-developers mailing list
> jrm...@li...
> https://lists.sourceforge.net/lists/listinfo/jrmtool-developers

Re: [jrmtool-developers] Copyrights, renaming, etc.

[Jacek R. <jac...@ul...>]

Hi,

I have just merged front-end changes into the trunk. I think we can go
ahead with proposed changes as I wouldn't worry about back-end changes
branch as I will probably recreate it after we apply those changes.

I can do the first two changes. 

For the first one I think I can do it semi-automatically so I don't need
to edit each file.

As for the package name change I would like to do it manually from
command line. This will make sure that we preserve all the history as
directory renames can be tricky and I don't trust Subclipse that much ;)

Just to clarify.

New package root: net.sf.jrmtool
New plug-in id: net.sf.jrmtool
New file header:
/*******************************************************************************
 * Copyright (c) 2004 - 2006 University Of British Columbia and others.
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 *
 * Contributors:
 *     University Of British Columbia - initial API and implementation
 *******************************************************************************/


So If you don't mind I'm willing to do this changes asap.

Has Martin Robillard agreed to import javadb sources into our
repository?


On Tue, 2006-04-25 at 16:29 -0700, Gail Murphy wrote:
> Hi,
>  
> I'd like to propose the following changes which I'm willing to do
> (coordinate in the case of one):
>       * Change all copyrights to EPL of the form below unless it was a
>         class added by others in which case it should be accurate in
>         the top line, last line:
> /*******************************************************************************
>  * Copyright (c) 2004 - 2006 University Of British Columbia and
> others.
>  * All rights reserved. This program and the accompanying materials
>  * are made available under the terms of the Eclipse Public License
> v1.0
>  * which accompanies this distribution, and is available at
>  * http://www.eclipse.org/legal/epl-v10.html
>  *
>  * Contributors:
>  *     University Of British Columbia - initial API and implementation
>  *******************************************************************************/
>  
>       * Switch to a net.sf.jrmtool (etc.) package naming to reflect
>         the fact that others are working on the code.
>       * Add a net.sf.jrmtool.test package for junit tests of
>         non-Eclipse parts of the system
>       * Add a net.sf.jrmtool.eclipse.test package for Eclipse-based
>         tests (perhaps non-automated tests for now)
>  
> I am emailing with Martin Robillard (creator of FEAT) about creating a
> separate entry under trunk: trunk/feat (if that's feasible) to
> incorporate the FEAT code under EPL. Hopefully we'll have an update on
> that available soon.
>  
> What is the process we are using on creating branches and doing
> merges? I'm reluctant to have too many branches outstanding (but maybe
> that's because I'm a naive subversion user). For instance, it seems
> like at least the front-end improvements (if they are working) should
> be merged to trunk before I create a branch to do the copyright change
> or renaming.
>  
> Gail.
>  
>  
-- 
Jacek Rosik <jac...@ul...>

Re: [jrmtool-developers] Copyrights, renaming, etc.

[Jacek R. <jac...@ul...>]

On 26 Apr 2006, at 00:29, Gail Murphy wrote:

> Hi,
>
> I'd like to propose the following changes which I'm willing to do  
> (coordinate in the case of one):
> Change all copyrights to EPL of the form below unless it was a  
> class added by others in which case it should be accurate in the  
> top line, last line:
> / 
> ********************************************************************** 
> *********
>  * Copyright (c) 2004 - 2006 University Of British Columbia and  
> others.
>  * All rights reserved. This program and the accompanying materials
>  * are made available under the terms of the Eclipse Public License  
> v1.0
>  * which accompanies this distribution, and is available at
>  * http://www.eclipse.org/legal/epl-v10.html
>  *
>  * Contributors:
>  *     University Of British Columbia - initial API and implementation
>   
> ********************************************************************** 
> *********/
>
> Switch to a net.sf.jrmtool (etc.) package naming to reflect the  
> fact that others are working on the code.
> Add a net.sf.jrmtool.test package for junit tests of non-Eclipse  
> parts of the system
> Add a net.sf.jrmtool.eclipse.test package for Eclipse-based tests  
> (perhaps non-automated tests for now
>
Fine by me.

>
> I am emailing with Martin Robillard (creator of FEAT) about  
> creating a separate entry under trunk: trunk/feat (if that's  
> feasible) to incorporate the FEAT code under EPL. Hopefully we'll  
> have an update on that available soon.
>
Yes, the plan is to create separate entry for javadb when importing  
Rory's (back-end) changes.

> What is the process we are using on creating branches and doing  
> merges? I'm reluctant to have too many branches outstanding (but  
> maybe that's because I'm a naive subversion user). For instance, it  
> seems like at least the front-end improvements (if they are  
> working) should be merged to trunk before I create a branch to do  
> the copyright change or renaming.

The plan is to merge those branches as soon as possible and them  
delete them (we can still access those branches later using  
subversion). With back-end we are hold off by legal issues. And with  
front-end I have found something I would like to get rid off before  
merging. Jonathan is using some internal JDT classes and I don't like  
it (and it shold not be done). I would like to get rid of those  
dependencies before merge. I'm currently in Poland, I'm comming back  
in 2 weeks, I should sort it out then. If you could wait with above  
mentioned changes that would be great.

As for branching, in subversion it is exactly like copying regular  
files/directories (although history is preserved), so you just create  
a directory under `branches' directory (that is only a convention,  
not obligation). Merging is also simple, you just specify two  
revisions/directories to `svn merge' command and changes introduced  
between those revisions are merged into current working copy. You may  
need to resolve some conflicts and then just commit merged changes  
(running some test before that is of course recomended). There is a  
support for merege in Eclipse/Subclipse, but I alwas prefered command  
line or tortoisesvn.  If you would like to merge front-end changes it  
would look like this:

$ cd /somepath/wc (where wc is checked out https:// 
svn.sourceforge.net/svnroot/jrmtool/trunk/jrmtool)
$ svn merge -r 4:10  https://svn.sourceforge.net/svnroot/jrmtool/ 
branches/frontend-improvements-1.0/jrmtool
...
resolve conflicts (supported by subcvlipse)
..
$svn commit (to commit merged changes)

In Eclipse/Subclipse merge dialog you just specify this url  https:// 
svn.sourceforge.net/svnroot/jrmtool/branches/frontend- 
improvements-1.0/jrmtool and revision range 4-10.

You can find much more here: http://svnbook.red-bean.com/
Here is a great SVN client for windows: http://tortoisesvn.tigris.org

I hope this is helpful. If you have any more questions please ask.

--
Jacek Rosik <jac...@ul...>

[jrmtool-developers] Copyrights, renaming, etc.

[Gail M. <mu...@cs...>]

Hi,
 
I'd like to propose the following changes which I'm willing to do
(coordinate in the case of one):

*	Change all copyrights to EPL of the form below unless it was a class
added by others in which case it should be accurate in the top line, last
line:

/***************************************************************************
****
 * Copyright (c) 2004 - 2006 University Of British Columbia and others.
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 *
 * Contributors:
 *     University Of British Columbia - initial API and implementation
 
****************************************************************************
***/
 

*	Switch to a net.sf.jrmtool (etc.) package naming to reflect the fact
that others are working on the code.
*	Add a net.sf.jrmtool.test package for junit tests of non-Eclipse
parts of the system
*	Add a net.sf.jrmtool.eclipse.test package for Eclipse-based tests
(perhaps non-automated tests for now)

 
I am emailing with Martin Robillard (creator of FEAT) about creating a
separate entry under trunk: trunk/feat (if that's feasible) to incorporate
the FEAT code under EPL. Hopefully we'll have an update on that available
soon.
 
What is the process we are using on creating branches and doing merges? I'm
reluctant to have too many branches outstanding (but maybe that's because
I'm a naive subversion user). For instance, it seems like at least the
front-end improvements (if they are working) should be merged to trunk
before I create a branch to do the copyright change or renaming.
 
Gail.
 
 

RE: [jrmtool-developers] Front-end changes

[Gail M. <mu...@cs...>]

 

> -----Original Message-----
> From: Jacek Rosik [mailto:jac...@ul...] 
> Sent: April 19, 2006 6:59 AM
> To: mu...@cs...
> Cc: 'jRMTool Developers List'
> Subject: RE: [jrmtool-developers] Front-end changes
> 
> On Tue, 2006-04-18 at 16:59 -0700, Gail Murphy wrote:
> > Hi Jacek,
> > 
> > A couple of questions (which might just be from my naiveness with
> > subversion):
> > 
> > 1. The classes in ro.nexource seem to be duplicates of the 
> > ca.ubc.cs.hyper package? I assume ro.nexource won't go to 
> the trunk? 
> > If it does, the package name needs improvement.
> Yep, this package is unused. Removed.
> 
> > 2. classes in ca.ubc.cs.hyper should go in 
> > ca.ubc.cs.jRMTool.eclipse.gui or at least under the jRMTool?
> Moved to ca.ubc.cs.jRMTool.eclipse.gui.
> 
> > We should perhaps revist the ca.ubc.cs package prefix.
> 
> For me personally it doesn't matter. But after the merge I 
> want to do some non source code changes to the plug-in 
> (converting to 3.x style, fixing manifest,  etc..) we can do 
> the change then. One thing i was going to do is to change 
> jRMTool package to jrmtool (lowercase), as this is java 
> package naming convention. Do you mind?

Changing to jrmtool is fine.

Let's stay with the prefix for now. I'm not enamoured with the
net.sf.jrmtool (but it might make the most sense).

> 
> If you want to change it what name do you suggest?
> net.sf.jrmtool
> net.sourceforge.jrmtool
> 
> > I haven't had a chance to run it but the description of the 
> > improvements sounds good. I'm fine with a merge into trunk.
> 
> I have run into some problems, but I don't think that they 
> are caused by the changes. Anyway the plan is to merge 
> frontend and backend changes into the trunk asap, and then 
> fix most serious bugs.
> 
> --
> Jacek Rosik <jac...@ul...>

Gail.

RE: [jrmtool-developers] Front-end changes

[Jacek R. <jac...@ul...>]

On Tue, 2006-04-18 at 16:59 -0700, Gail Murphy wrote:
> Hi Jacek,
> 
> A couple of questions (which might just be from my naiveness with
> subversion):
> 
> 1. The classes in ro.nexource seem to be duplicates of the ca.ubc.cs.hyper
> package? I assume ro.nexource won't go to the trunk? If it does, the package
> name needs improvement.
Yep, this package is unused. Removed.

> 2. classes in ca.ubc.cs.hyper should go in ca.ubc.cs.jRMTool.eclipse.gui or
> at least under the jRMTool?
Moved to ca.ubc.cs.jRMTool.eclipse.gui.

> We should perhaps revist the ca.ubc.cs package prefix.

For me personally it doesn't matter. But after the merge I want to do
some non source code changes to the plug-in (converting to 3.x style,
fixing manifest,  etc..) we can do the change then. One thing i was
going to do is to change jRMTool package to jrmtool (lowercase), as this
is java package naming convention. Do you mind?

If you want to change it what name do you suggest?
net.sf.jrmtool
net.sourceforge.jrmtool

> I haven't had a chance to run it but the description of the improvements
> sounds good. I'm fine with a merge into trunk. 

I have run into some problems, but I don't think that they are caused by
the changes. Anyway the plan is to merge frontend and backend changes
into the trunk asap, and then fix most serious bugs.

-- 
Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Front-end changes

[Gail M. <mu...@cs...>]

Hi Jacek,

A couple of questions (which might just be from my naiveness with
subversion):

1. The classes in ro.nexource seem to be duplicates of the ca.ubc.cs.hyper
package? I assume ro.nexource won't go to the trunk? If it does, the package
name needs improvement.

2. classes in ca.ubc.cs.hyper should go in ca.ubc.cs.jRMTool.eclipse.gui or
at least under the jRMTool?

We should perhaps revist the ca.ubc.cs package prefix.

I haven't had a chance to run it but the description of the improvements
sounds good. I'm fine with a merge into trunk. 

Gail.

> -----Original Message-----
> From: jrm...@li... 
> [mailto:jrm...@li...] On 
> Behalf Of Jacek Rosik
> Sent: April 18, 2006 5:08 AM
> To: jRMTool Developers List
> Subject: [jrmtool-developers] Front-end changes
> 
> Hi,
> 
> I have just committed Jonathan's changes into 
> `frontend-improvements-1.0' branch. Gail could you take a 
> look at those changes and comment? If there are no objections 
> If there are no objections would like to merge those changes 
> into the trunk on thursday.
> 
> Regards,
> --
> Jacek Rosik <jac...@ul...>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking 
> scripting language
> that extends applications into web and mobile media. Attend 
> the live webcast
> and join the prime developer group breaking into this new 
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&
> dat=121642
> _______________________________________________
> jrmtool-developers mailing list
> jrm...@li...
> https://lists.sourceforge.net/lists/listinfo/jrmtool-developers

[jrmtool-developers] Front-end changes

[Jacek R. <jac...@ul...>]

Hi,

I have just committed Jonathan's changes into
`frontend-improvements-1.0' branch. Gail could you take a look at those
changes and comment? If there are no objections If there are no
objections would like to merge those changes into the trunk on thursday.

Regards,
-- 
Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Problems with JavaDB license

[Gail M. <mu...@cs...>]

A holding pattern for now. I talked with Martin briefly and he is amenable
to an EPL license on the code. Let me follow up and firm it up. Probably
won't have a response until next week.

Gail. 

> -----Original Message-----
> From: jrm...@li... 
> [mailto:jrm...@li...] On 
> Behalf Of Jacek Rosik
> Sent: April 13, 2006 8:30 AM
> To: jRMTool Developers List
> Cc: Rory Cosgrove
> Subject: [jrmtool-developers] Problems with JavaDB license
> 
> Hi,
> 
> Rory's changes to jRMTool plug-in (back-end improvements) 
> include some modifications to JavaDB code. He used JavaDB 
> version from author's website which i think is v1.1. 
> 
> The problem is that this version is GPL licensed, so we 
> cannot integrate it into a CPL or EPL licensed product. The 
> only solution is that the author will give us an explicit 
> permission to use it in our project on different license 
> terms or he will re-release it under a different license 
> (LGPL should be fine, cream is LGPL anyway).
> 
> Switching to the older version used originally in the plug-in 
> is not a solution as we do not have permission from the 
> author to modify it anyway (Gail, do we?).
> 
> Gail, Rory could you discuss this with the author of JavaDB. 
> You are in much better contact with him than I am. Until this 
> issue is resolved I will not be able to commit Rory's changes.
> 
> Regards,
> --
> Jacek Rosik <jac...@ul...>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking 
> scripting language
> that extends applications into web and mobile media. Attend 
> the live webcast
> and join the prime developer group breaking into this new 
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&
> dat=121642
> _______________________________________________
> jrmtool-developers mailing list
> jrm...@li...
> https://lists.sourceforge.net/lists/listinfo/jrmtool-developers

[jrmtool-developers] Problems with JavaDB license

[Jacek R. <jac...@ul...>]

Hi,

Rory's changes to jRMTool plug-in (back-end improvements) include some
modifications to JavaDB code. He used JavaDB version from author's
website which i think is v1.1. 

The problem is that this version is GPL licensed, so we cannot integrate
it into a CPL or EPL licensed product. The only solution is that the
author will give us an explicit permission to use it in our project on
different license terms or he will re-release it under a different
license (LGPL should be fine, cream is LGPL anyway).

Switching to the older version used originally in the plug-in is not a
solution as we do not have permission from the author to modify it
anyway (Gail, do we?).

Gail, Rory could you discuss this with the author of JavaDB. You are in
much better contact with him than I am. Until this issue is resolved I
will not be able to commit Rory's changes.

Regards,
-- 
Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Trackers setup

[Jacek R. <jac...@ul...>]

Hi,

On Tue, 2006-04-11 at 09:59 -0700, Gail Murphy wrote:
> Sounds good. 

I finished trackers setup. In 'Support Requests' tracker I have added
only 'install' category, we can add others later.

Andy, could you send send a mail to people using reflection about the
trackers? Most important for us are probably 'Bugs' and 'Feature'
trackers:

Bugs http://sourceforge.net/tracker/?group_id=98003&atid=619749
Features: http://sourceforge.net/tracker/?group_id=98003&atid=619752

In order to file a bug or feature request they need to be logged in.
This implies that they need to create an account on sourceforge (if they
don't have one already). Here is link:

http://sourceforge.net/account/newuser_emailverify.php

Cheers,

> > -----Original Message-----
> > From: Jacek Rosik [mailto:jac...@ul...] 
> > Sent: April 11, 2006 10:02 AM
> > To: mu...@cs...
> > Cc: 'jRMTool Developers'
> > Subject: RE: [jrmtool-developers] Trackers setup
> > 
> > Hi,
> > 
> > On Tue, 2006-04-11 at 09:42 -0700, Gail Murphy wrote: 
> > > Sure. The fewer categories the better. Its often pretty hard to 
> > > distinguish between them. Do you have privledge to do this? G.
> > 
> > Yes, except support requests tracker. I can do it if this list ok?
> > 
> > "generic"
> > "reflexion model"
> > "speed/robustness"
> > "user interface"
> > 
> > I wouldn't add "parsing" right now. I can't think of a user 
> > visible part of the process which would fall into this 
> > category and as you said fewer categories the better. If we 
> > find a bug which would nicely fall into this category we can 
> > always add it later.
> > 
> > --
> > Jacek Rosik <jac...@ul...>
> 
-- 
Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Switch to Subversion

[Jacek R. <jac...@ul...>]

Hi Gail,

On Tue, 2006-04-11 at 09:52 -0700, Gail Murphy wrote:
> Hi Jacek,
> 
> You should have permission for pretty much everything now. Check it out. 

Yep, it's working. I have just tagged 1.0.0 release and it worked. I
should start committing some code tomorrow.

Thanks!

> > -----Original Message-----
> > From: Jacek Rosik [mailto:jac...@ul...] 
> > Sent: April 11, 2006 6:17 AM
> > To: mu...@cs...
> > Cc: 'jRMTool Developers'
> > Subject: RE: [jrmtool-developers] Switch to Subversion
> > 
> > On Tue, 2006-04-04 at 21:03 -0700, Gail Murphy wrote:
> > > Hi Jacek,
> > > 
> > > > -----Original Message-----
> > > > From: Jacek Rosik [mailto:jac...@ul...]
> > > > Sent: April 4, 2006 5:18 PM
> > > > To: mu...@cs...
> > > > Cc: jRMTool Developers
> > > > Subject: Re: [jrmtool-developers] Switch to Subversion
> > > > 
> > > > Hi Gail
> > > > 
> > > > On 4 Apr 2006, at 18:46, Gail Murphy wrote:
> > > > [snip]
> > > > >>
> > > > >> Converted repository is already uploaded to 
> > SourceForge. The only 
> > > > >> thing left now is to enable Subversion access and disable
> > > > CVS access. 
> > > > >> We could leave CVS repository enabled but I think it 
> > would only 
> > > > >> confuse users as I don't think we are going to update it.
> > > > Gail, could
> > > > >> you do it?
> > > > 
> > > > Any progress on this? I tried to do it but I couldn't, probably 
> > > > administrative rights again.
> > > > 
> > > > Subversion repository is already on SF. You can access it at:
> > > > https://svn.sourceforge.net/svnroot/jrmtool/
> > > > The required change is only to make subversion option visible on 
> > > > jrmtool project page.
> > > 
> > > Should be accessible now.
> > > 
> > 
> > I have just tried to commit some code an it failed. I suppose 
> > that you need to enable subversion access for me. here is more info:
> > https://sourceforge.net/docs/E09#permissions
> > 
> > [snip]
> > 
> > --
> > Jacek Rosik <jac...@ul...>
> 
-- 
Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Trackers setup

[Gail M. <mu...@cs...>]

Sounds good. 

> -----Original Message-----
> From: Jacek Rosik [mailto:jac...@ul...] 
> Sent: April 11, 2006 10:02 AM
> To: mu...@cs...
> Cc: 'jRMTool Developers'
> Subject: RE: [jrmtool-developers] Trackers setup
> 
> Hi,
> 
> On Tue, 2006-04-11 at 09:42 -0700, Gail Murphy wrote: 
> > Sure. The fewer categories the better. Its often pretty hard to 
> > distinguish between them. Do you have privledge to do this? G.
> 
> Yes, except support requests tracker. I can do it if this list ok?
> 
> "generic"
> "reflexion model"
> "speed/robustness"
> "user interface"
> 
> I wouldn't add "parsing" right now. I can't think of a user 
> visible part of the process which would fall into this 
> category and as you said fewer categories the better. If we 
> find a bug which would nicely fall into this category we can 
> always add it later.
> 
> --
> Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Trackers setup

[Jacek R. <jac...@ul...>]

Hi,

On Tue, 2006-04-11 at 09:42 -0700, Gail Murphy wrote: 
> Sure. The fewer categories the better. Its often pretty hard to distinguish
> between them. Do you have privledge to do this? G. 

Yes, except support requests tracker. I can do it if this list ok?

"generic"
"reflexion model"
"speed/robustness"
"user interface"

I wouldn't add "parsing" right now. I can't think of a user visible part
of the process which would fall into this category and as you said fewer
categories the better. If we find a bug which would nicely fall into
this category we can always add it later.

-- 
Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Switch to Subversion

[Gail M. <mu...@cs...>]

Subversion scripts enabled.

Commit notifications are on and will be sent (w/o diffs) to
jrm...@li....

To subscribe, see:
https://lists.sourceforge.net/lists/listinfo/jrmtool-revnotify

Gail. 

> -----Original Message-----
> From: Jacek Rosik [mailto:jac...@ul...] 
> Sent: April 11, 2006 5:59 AM
> To: mu...@cs...
> Cc: 'jRMTool Developers'
> Subject: RE: [jrmtool-developers] Switch to Subversion
> 
> Hi Gail,
> 
> On Tue, 2006-04-04 at 21:03 -0700, Gail Murphy wrote:
> > Hi Jacek,
> > 
> > > -----Original Message-----
> > > From: Jacek Rosik [mailto:jac...@ul...]
> > > Sent: April 4, 2006 5:18 PM
> > > To: mu...@cs...
> > > Cc: jRMTool Developers
> > > Subject: Re: [jrmtool-developers] Switch to Subversion
> > > 
> > > Hi Gail
> > > 
> > > On 4 Apr 2006, at 18:46, Gail Murphy wrote:
> > > [snip]
> > > >>
> > > >> Converted repository is already uploaded to 
> SourceForge. The only 
> > > >> thing left now is to enable Subversion access and disable
> > > CVS access. 
> > > >> We could leave CVS repository enabled but I think it 
> would only 
> > > >> confuse users as I don't think we are going to update it.
> > > Gail, could
> > > >> you do it?
> > > 
> > > Any progress on this? I tried to do it but I couldn't, probably 
> > > administrative rights again.
> > > 
> > > Subversion repository is already on SF. You can access it at:
> > > https://svn.sourceforge.net/svnroot/jrmtool/
> > > The required change is only to make subversion option visible on 
> > > jrmtool project page.
> > 
> > Should be accessible now.
> 
> Yes, it is accessible. One more thing though. Could You 
> enable two subversion scripts (last option at the bottom of 
> the subversion configuration page)? Those scripts are 
> 'check-case-insensitive.py' and 'check-mime-type.py'. First 
> would be useful to make sure that we won't have any name 
> conflicts on windows machines and second one will ensure that 
> binary files are treated as binary files.
> 
> You could also create a new list for commit messages and 
> enable 'svnnotify.py' script to feed this list. But I don't 
> think that is necessary as I will be the only contributor for 
> a while. On the other hand it is quite nice feature if we 
> have more contributors as everyone will be notified of the 
> changes. Anyway if you decide to do it I'd rather have commit 
> messages w/o diffs in them.
> 
> > > 
> > > [snip]
> > > >> * Create branch for version 1.0.x. All new features 
> will go into 
> > > >> trunk and will form 1.1.x releases. We can port some 
> bugfixes to 
> > > >> 1.0.x branch but I don't think there is a need for that.
> > > >
> > > > Seems right. To be clear, the intended target is Eclipse 3.1?
> > > >
> > > > Should we start a branch that investigates Eclipse 3.2 
> support? (I 
> > > > would be interested in looking into this)
> > > 
> > > As me or Andrew mentioned before we would rather target 3.x. 
> > > We can't force of our users to use any specific version 
> of Eclipse. 
> > > It shouldn't be too hard I suppose. If it proves 
> otherwise, then we 
> > > can
> > > investigate possibilities of supporting only selected 
> minor   versio.
> > 
> > Always preferable but a reasonable number of small changes 
> are likely 
> > necessary to support 3.2 (based on our experience 
> developing other plugins).
> 
> Yes, that is probably true. What I mean is that we have make 
> sure that those changes won't break backward compatibility 
> (If it's possible).
> 
> > > 
> > > >
> > > >> * After this I'm going to get rid of some files from
> > > repository which
> > > >> shouldn't be there. For example .classpath JavaDB.jar. 
> > > Then I'm going
> > > >> to import JavaDB source into repository (need permission
> > > from author,
> > > >> any update on this Gail?). The reason for this is that some of 
> > > >> our modifications
> > > >
> > > > I'm checking into putting in source. For now, we do *not* have 
> > > > permission.
> > > 
> > > We need that before I'll be able to commit Rory's changes (backend
> > > improvements) as he has modified JavaDB itself.
> > > 
> > > > Also, we need to deal with licenses. I would like to move
> > > everything
> > > > onto an EPL license. Other thoughts?
> > > >
> > > I always get nautious when it comes to legal stuff. 
> > > Personally I use either GPL or MIT/BSD I don't even try to read 
> > > other licenses ;).
> > > Anyway I'll read EPL and compare it to CPL and let you 
> know what I'm 
> > > thinking about it.
> > 
> > EPL is the next genesis of CPL. I won't contribute to any 
> GPL code but 
> > that's another story.
> EPL is fine by me. If you want to change license to EPL, 
> please do so. I would like this change to happen before I 
> commit code contributed by FYP students. I want to have their 
> explicit permission to publish their work under the terms of 
> specific license.
> 
> 
> --
> Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Switch to Subversion

[Gail M. <mu...@cs...>]

Hi Jacek,

You should have permission for pretty much everything now. Check it out. 

G. 

> -----Original Message-----
> From: Jacek Rosik [mailto:jac...@ul...] 
> Sent: April 11, 2006 6:17 AM
> To: mu...@cs...
> Cc: 'jRMTool Developers'
> Subject: RE: [jrmtool-developers] Switch to Subversion
> 
> On Tue, 2006-04-04 at 21:03 -0700, Gail Murphy wrote:
> > Hi Jacek,
> > 
> > > -----Original Message-----
> > > From: Jacek Rosik [mailto:jac...@ul...]
> > > Sent: April 4, 2006 5:18 PM
> > > To: mu...@cs...
> > > Cc: jRMTool Developers
> > > Subject: Re: [jrmtool-developers] Switch to Subversion
> > > 
> > > Hi Gail
> > > 
> > > On 4 Apr 2006, at 18:46, Gail Murphy wrote:
> > > [snip]
> > > >>
> > > >> Converted repository is already uploaded to 
> SourceForge. The only 
> > > >> thing left now is to enable Subversion access and disable
> > > CVS access. 
> > > >> We could leave CVS repository enabled but I think it 
> would only 
> > > >> confuse users as I don't think we are going to update it.
> > > Gail, could
> > > >> you do it?
> > > 
> > > Any progress on this? I tried to do it but I couldn't, probably 
> > > administrative rights again.
> > > 
> > > Subversion repository is already on SF. You can access it at:
> > > https://svn.sourceforge.net/svnroot/jrmtool/
> > > The required change is only to make subversion option visible on 
> > > jrmtool project page.
> > 
> > Should be accessible now.
> > 
> 
> I have just tried to commit some code an it failed. I suppose 
> that you need to enable subversion access for me. here is more info:
> https://sourceforge.net/docs/E09#permissions
> 
> [snip]
> 
> --
> Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Trackers setup

[Gail M. <mu...@cs...>]

Sure. The fewer categories the better. Its often pretty hard to distinguish
between them. Do you have privledge to do this? G. 

> -----Original Message-----
> From: Jacek Rosik [mailto:jac...@ul...] 
> Sent: April 11, 2006 5:13 AM
> To: mu...@cs...
> Cc: 'jRMTool Developers'
> Subject: RE: [jrmtool-developers] Trackers setup
> 
> On Mon, 2006-04-10 at 20:18 -0700, Gail Murphy wrote:
> > Hi Jacek,
> > 
> > I've created "jrmtool-notifications" as a new list (waiting 
> for it to 
> > be set up). This way someone can participate o the developers list 
> > without getting all the notifications.
> 
> Good idea!
> 
> > I suggest we refine categories after we've used them some. 
> I thought 
> > we could just start with a few general ones. Once we are more 
> > user-oriented we can move over to other categories.
> 
> Yep, that's a good plan. But :) unfortunately sourceforge's 
> bug tracking system It won't allow you to change categories 
> once they are added. Or more precisely, if you change a 
> category, it will be changed in all existing bugs which use 
> this category. :(
> 
> What I suggest is that we start with pretty general 
> categories and ad more specific ones later on.
> 
> Here is my list (same categories for all trackers),:
> "generic"
> "reflexion model"
> "speed/robustness"
> "user interface"
> 
> and maybe those:
> "import/export"
> "language support" / "java support"
> 
> What do you think about those?
> 
> > Gail. 
> 
> --
> Jacek Rosik <jac...@ul...>

Re: [jrmtool-developers] Trackers setup

[Andrew Le G. <and...@ul...>]

Can I suggest a category named 'parsing' instead of 'source model 
extraction'



Jacek Rosik wrote:

>On Mon, 2006-04-10 at 20:18 -0700, Gail Murphy wrote:
>  
>
>>Hi Jacek,
>>
>>I've created "jrmtool-notifications" as a new list (waiting for it to be set
>>up). This way someone can participate o the developers list without getting
>>all the notifications.
>>    
>>
>
>Good idea!
>
>  
>
>>I suggest we refine categories after we've used them some. I thought we
>>could just start with a few general ones. Once we are more user-oriented we
>>can move over to other categories.
>>    
>>
>
>Yep, that's a good plan. But :) unfortunately sourceforge's bug tracking
>system It won't allow you to change categories once they are added. Or
>more precisely, if you change a category, it will be changed in all
>existing bugs which use this category. :(
>
>What I suggest is that we start with pretty general categories and ad
>more specific ones later on.
>
>Here is my list (same categories for all trackers),:
>"generic"
>"reflexion model"
>"speed/robustness"
>"user interface"
>
>and maybe those:
>"import/export"
>"language support" / "java support"
>
>What do you think about those?
>
>  
>
>>Gail. 
>>    
>>
>
>  
>

RE: [jrmtool-developers] Switch to Subversion

[Jacek R. <jac...@ul...>]

On Tue, 2006-04-04 at 21:03 -0700, Gail Murphy wrote:
> Hi Jacek, 
> 
> > -----Original Message-----
> > From: Jacek Rosik [mailto:jac...@ul...] 
> > Sent: April 4, 2006 5:18 PM
> > To: mu...@cs...
> > Cc: jRMTool Developers
> > Subject: Re: [jrmtool-developers] Switch to Subversion
> > 
> > Hi Gail
> > 
> > On 4 Apr 2006, at 18:46, Gail Murphy wrote:
> > [snip]
> > >>
> > >> Converted repository is already uploaded to SourceForge. The only 
> > >> thing left now is to enable Subversion access and disable 
> > CVS access. 
> > >> We could leave CVS repository enabled but I think it would only 
> > >> confuse users as I don't think we are going to update it. 
> > Gail, could 
> > >> you do it?
> > 
> > Any progress on this? I tried to do it but I couldn't, 
> > probably administrative rights again.
> > 
> > Subversion repository is already on SF. You can access it at:
> > https://svn.sourceforge.net/svnroot/jrmtool/
> > The required change is only to make subversion option visible 
> > on jrmtool project page.
> 
> Should be accessible now.
> 

I have just tried to commit some code an it failed. I suppose that you
need to enable subversion access for me. here is more info:
https://sourceforge.net/docs/E09#permissions

[snip]

-- 
Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Switch to Subversion

[Jacek R. <jac...@ul...>]

Hi Gail,

On Tue, 2006-04-04 at 21:03 -0700, Gail Murphy wrote:
> Hi Jacek, 
> 
> > -----Original Message-----
> > From: Jacek Rosik [mailto:jac...@ul...] 
> > Sent: April 4, 2006 5:18 PM
> > To: mu...@cs...
> > Cc: jRMTool Developers
> > Subject: Re: [jrmtool-developers] Switch to Subversion
> > 
> > Hi Gail
> > 
> > On 4 Apr 2006, at 18:46, Gail Murphy wrote:
> > [snip]
> > >>
> > >> Converted repository is already uploaded to SourceForge. The only 
> > >> thing left now is to enable Subversion access and disable 
> > CVS access. 
> > >> We could leave CVS repository enabled but I think it would only 
> > >> confuse users as I don't think we are going to update it. 
> > Gail, could 
> > >> you do it?
> > 
> > Any progress on this? I tried to do it but I couldn't, 
> > probably administrative rights again.
> > 
> > Subversion repository is already on SF. You can access it at:
> > https://svn.sourceforge.net/svnroot/jrmtool/
> > The required change is only to make subversion option visible 
> > on jrmtool project page.
> 
> Should be accessible now.

Yes, it is accessible. One more thing though. Could You enable two
subversion scripts (last option at the bottom of the subversion
configuration page)? Those scripts are 'check-case-insensitive.py' and
'check-mime-type.py'. First would be useful to make sure that we won't
have any name conflicts on windows machines and second one will ensure
that binary files are treated as binary files.

You could also create a new list for commit messages and enable
'svnnotify.py' script to feed this list. But I don't think that is
necessary as I will be the only contributor for a while. On the other
hand it is quite nice feature if we have more contributors as everyone
will be notified of the changes. Anyway if you decide to do it I'd
rather have commit messages w/o diffs in them.

> > 
> > [snip]
> > >> * Create branch for version 1.0.x. All new features will go into 
> > >> trunk and will form 1.1.x releases. We can port some bugfixes to 
> > >> 1.0.x branch but I don't think there is a need for that.
> > >
> > > Seems right. To be clear, the intended target is Eclipse 3.1?
> > >
> > > Should we start a branch that investigates Eclipse 3.2 support? (I 
> > > would be interested in looking into this)
> > 
> > As me or Andrew mentioned before we would rather target 3.x. 
> > We can't force of our users to use any specific version of 
> > Eclipse. It shouldn't be too hard I suppose. If it proves 
> > otherwise, then we can  
> > investigate possibilities of supporting only selected minor   versio.
> 
> Always preferable but a reasonable number of small changes are likely
> necessary to support 3.2 (based on our experience developing other plugins).

Yes, that is probably true. What I mean is that we have make sure that
those changes won't break backward compatibility (If it's possible).

> > 
> > >
> > >> * After this I'm going to get rid of some files from 
> > repository which 
> > >> shouldn't be there. For example .classpath JavaDB.jar. 
> > Then I'm going 
> > >> to import JavaDB source into repository (need permission 
> > from author, 
> > >> any update on this Gail?). The reason for this is that some of our 
> > >> modifications
> > >
> > > I'm checking into putting in source. For now, we do *not* have 
> > > permission.
> > 
> > We need that before I'll be able to commit Rory's changes (backend
> > improvements) as he has modified JavaDB itself.
> > 
> > > Also, we need to deal with licenses. I would like to move 
> > everything 
> > > onto an EPL license. Other thoughts?
> > >
> > I always get nautious when it comes to legal stuff. 
> > Personally I use either GPL or MIT/BSD I don't even try to 
> > read other licenses ;).  
> > Anyway I'll read EPL and compare it to CPL and let you know 
> > what I'm thinking about it.
> 
> EPL is the next genesis of CPL. I won't contribute to any GPL code but
> that's another story.
EPL is fine by me. If you want to change license to EPL, please do so. I
would like this change to happen before I commit code contributed by FYP
students. I want to have their explicit permission to publish their work
under the terms of specific license.


-- 
Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Trackers setup

[Jacek R. <jac...@ul...>]

On Mon, 2006-04-10 at 20:18 -0700, Gail Murphy wrote:
> Hi Jacek,
> 
> I've created "jrmtool-notifications" as a new list (waiting for it to be set
> up). This way someone can participate o the developers list without getting
> all the notifications.

Good idea!

> I suggest we refine categories after we've used them some. I thought we
> could just start with a few general ones. Once we are more user-oriented we
> can move over to other categories.

Yep, that's a good plan. But :) unfortunately sourceforge's bug tracking
system It won't allow you to change categories once they are added. Or
more precisely, if you change a category, it will be changed in all
existing bugs which use this category. :(

What I suggest is that we start with pretty general categories and ad
more specific ones later on.

Here is my list (same categories for all trackers),:
"generic"
"reflexion model"
"speed/robustness"
"user interface"

and maybe those:
"import/export"
"language support" / "java support"

What do you think about those?

> Gail. 

-- 
Jacek Rosik <jac...@ul...>

[jrmtool-developers] Notifications List

[Gail M. <mu...@cs...>]

An email list for notifications (jrmtool-notifications) about tracker
updates jRMTool development is available through:

 <https://lists.sourceforge.net/lists/listinfo/jrmtool-notifications>
https://lists.sourceforge.net/lists/listinfo/jrmtool-notifications

Joining this list will mean you should get notifications about changes in
the bug notification tracker, support requests tracker, patches tracker and
feature request tracker.
 
Gail.
 

RE: [jrmtool-developers] Trackers setup

[Gail M. <mu...@cs...>]

Hi Jacek,

I've created "jrmtool-notifications" as a new list (waiting for it to be set
up). This way someone can participate o the developers list without getting
all the notifications.

I suggest we refine categories after we've used them some. I thought we
could just start with a few general ones. Once we are more user-oriented we
can move over to other categories.

Gail. 

> -----Original Message-----
> From: Jacek Rosik [mailto:jac...@ul...] 
> Sent: April 10, 2006 6:55 AM
> To: mu...@cs...
> Cc: 'jRMTool Developers'
> Subject: RE: [jrmtool-developers] Trackers setup
> 
> On Thu, 2006-03-30 at 21:33 -0800, Gail Murphy wrote:
> > I did some setup on these and added you as an administrator Jacek.
> > 
> > Gail. 
> 
> Hi Gail,
> 
> I have modified group settings, currently two options consist 
> of 'Trunk/Snapshots' and `Version 1.0.0'.
> 
> I think that categories could also be refined. Current 
> categories are a bit to technical in my opinion. I don't 
> think that users will be able to tell the difference between 
> 'computation improvements' or 'sm model extraction 
> improvements' for example. Those categories should be more 
> 'user view' oriented. I'll try to come up with updated list 
> sometime this week.
> 
> Could you please change option to send notification email to 
> `jrm...@li...' instead only to 
> you? In this way either of us could react to new reports.
> 
> --
> Jacek Rosik <jac...@ul...>

RE: [jrmtool-developers] Trackers setup

[Jacek R. <jac...@ul...>]

On Thu, 2006-03-30 at 21:33 -0800, Gail Murphy wrote:
> I did some setup on these and added you as an administrator Jacek.
> 
> Gail. 

Hi Gail,

I have modified group settings, currently two options consist of
'Trunk/Snapshots' and `Version 1.0.0'.

I think that categories could also be refined. Current categories are a
bit to technical in my opinion. I don't think that users will be able to
tell the difference between 'computation improvements' or 'sm model
extraction improvements' for example. Those categories should be more
'user view' oriented. I'll try to come up with updated list sometime
this week.

Could you please change option to send notification email to
`jrm...@li...' instead only to you? In this
way either of us could react to new reports.

-- 
Jacek Rosik <jac...@ul...>