GSoC/plugin project templates

Hello all,

Approximately two months ago we had some students in the
university 
working on plugins for sip-communicator. I had told them at
the time 
that for their projects they could simply clone the
sip-communicator 
repository, commit all code to their own project
repositories and start 
modifying the new repo to add functionality.

As a result we had lots of problems. First, whenever the
students would 
discover a problem with the code, they couldn't really use
our fix since 
their repositories were out of sync.

Then, there was also the merging problem. If we wanted to
use any of 
their code back in SC, we had to first spend some time
making it work 
with the latest version.

And I am not even mentioning the fact that one had to make
so many 
commits in order to upload sc that we had *four* of the
student projects 
making the "top 10 by commits" column on java.net
for January and February:

http://community.java.net/projects/
toparchive.csp?year=2007&month=January
http://community.java.net/projects
/toparchive.csp?year=2007&month=February

(look for the sc- prefixes)

Hence, I've been thinking for some time now that we should
have a 
project template that makes it easy to write plugins without
having to 
clone the whole sip-communicator repository and that would
allow you to 
stay up to date.

Such a project template would have to copy the directory
structure of 
sip-communicator (i.e. it will have to have src, classes,
lib, and 
resources directories) but not its contents.

The tricky part is that in the new project you'd still have
dependencies 
on sip-communicator libs. The best thing to do in order to
resolve that 
is to simply assume that the developer using the template
would have 
sip-communicator's sources in the same directory as the
template itself.

For example, in a case where John Doe is working on some
project called 
"SC BASED PROJECT", he would have the following
structure:

/home/johndoe/projects
/home/johndoe/projects/sip-communicator
/home/johndoe/projects/sc-based-project

The build.xml file of the template (sc-based-project) would
therefore be 
able to include all necessary libs from sip-communicator by
referencing 
them as.

../sip-communicator/lib/**/*.jar

Times are more than ripe now since the google summer of code
students 
could all use such a template.

So I guess my question is: Is there a volunteer that would
like to 
create and maintain such a java.net project that could be
used as a 
template by new developers?

I know that the irc4sc guys (http://irc4sc.dev.java.net
) are using the 
mechanism so whoever takes that up would be able to use
their structure 
as an example.

So, any takers?

Emil

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hey Mihai,

Glad to hear that! I can create a sip-communicator
subproject for you if 
you want, just let me know.

And of course, don't hesitate if you have any questions!

Cheers
Emil

Mihai Balan wrote:
> Sound pretty interesting to me. If no one else is
willing to "take over 
> it", I'll give it a try. Though not earlier than
this weekend (lots of 
> school stuff over my head). I hope I'll found the
support needed 
> 
> Cheers,
> Mihai Balan
> 
> On 4/23/07, *Emil Ivov* <emchoemcho.com
<mailto:emchoemcho.com>> wrote:
> 
>     Hello all,
> 
>     Approximately two months ago we had some students
in the university
>     working on plugins for sip-communicator. I had told
them at the time
>     that for their projects they could simply clone the
sip-communicator
>     repository, commit all code to their own project
repositories and start
>     modifying the new repo to add functionality.
> 
>     As a result we had lots of problems. First,
whenever the students would
>     discover a problem with the code, they couldn't
really use our fix
>     since
>     their repositories were out of sync.
> 
>     Then, there was also the merging problem. If we
wanted to use any of
>     their code back in SC, we had to first spend some
time making it work
>     with the latest version.
> 
>     And I am not even mentioning the fact that one had
to make so many
>     commits in order to upload sc that we had *four* of
the student projects
>     making the "top 10 by commits" column on
java.net <http://java.net>
>     for January and February:
> 
>     http://community.java.net/projects/
toparchive.csp?year=2007&month=January
>     <http://community.java.net/proje
cts/toparchive.csp?year=2007&month=January>
>     http://community.java.net/projects
/toparchive.csp?year=2007&month=February
>     <http://community.java.net/proj
ects/toparchive.csp?year=2007&month=February>
> 
>     (look for the sc- prefixes)
> 
>     Hence, I've been thinking for some time now that we
should have a
>     project template that makes it easy to write
plugins without having to
>     clone the whole sip-communicator repository and
that would allow you to
>     stay up to date.
> 
>     Such a project template would have to copy the
directory structure of
>     sip-communicator (i.e. it will have to have src,
classes, lib, and
>     resources directories) but not its contents.
> 
>     The tricky part is that in the new project you'd
still have dependencies
>     on sip-communicator libs. The best thing to do in
order to resolve that
>     is to simply assume that the developer using the
template would have
>     sip-communicator's sources in the same directory as
the template itself.
> 
>     For example, in a case where John Doe is working on
some project called
>     "SC BASED PROJECT", he would have the
following structure:
> 
>     /home/johndoe/projects
>     /home/johndoe/projects/sip-communicator
>     /home/johndoe/projects/sc-based-project
> 
>     The build.xml file of the template
(sc-based-project) would therefore be
>     able to include all necessary libs from
sip-communicator by referencing
>     them as.
> 
>     ../sip-communicator/lib/**/*.jar
> 
>     Times are more than ripe now since the google
summer of code students
>     could all use such a template.
> 
>     So I guess my question is: Is there a volunteer
that would like to
>     create and maintain such a java.net <http://java.net> project
that
>     could be used as a
>     template by new developers?
> 
>     I know that the irc4sc guys (http://irc4sc.dev.java.net

>     <http://irc4sc.dev.java
.net>) are using the
>     mechanism so whoever takes that up would be able to
use their structure
>     as an example.
> 
>     So, any takers?
> 
>     Emil
> 
>    
------------------------------------------------------------
---------
>     To unsubscribe, e-mail:
>     dev-unsubscribesip-communicator.dev.java.net
>     <mailto:dev-unsubscribesip-communicator.dev.java.net>
>     For additional commands, e-mail:
>     dev-helpsip-communicator.dev.java.net
>     <mailto:dev-helpsip-communicator.dev.java.net>
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi all,

I can also help you guys if you need some help (as far as
I'm not an Ant 
expert).

One possible way to create a build.xml adapted to
sub-projects could be to :
- modify the original build.xml as described here : 
ht
tp://ant.apache.org/manual/CoreTasks/import.html
- create an some empty tasks like
"sub-project-compile", ... in this 
build.xml
- create a new build.xml for the sub-project
- import the main build.xml in the sub-project's build.xml
- overwrite the sub-project tasks to achieve some specific
tasks to the 
sub-project

What do you think about it ?

Ben

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hey Ben, good idea!

I haven't really been thinking about modifying the top level
build.xml 
but what you suggest sounds quite reasonable!

Emil



Benoit Pradelle wrote:
> Hi all,
> 
> I can also help you guys if you need some help (as far
as I'm not an Ant 
> expert).
> 
> One possible way to create a build.xml adapted to
sub-projects could be to :
> - modify the original build.xml as described here : 
> ht
tp://ant.apache.org/manual/CoreTasks/import.html
> - create an some empty tasks like
"sub-project-compile", ... in this 
> build.xml
> - create a new build.xml for the sub-project
> - import the main build.xml in the sub-project's
build.xml
> - overwrite the sub-project tasks to achieve some
specific tasks to the 
> sub-project
> 
> What do you think about it ?
> 
> Ben
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hey,

What has become this project ? Has a subproject been created
? Someone 
started to work on it ?

Cheers,
Ben

Emil Ivov a écrit :
> Hello all,
>
> Approximately two months ago we had some students in
the university 
> working on plugins for sip-communicator. I had told
them at the time 
> that for their projects they could simply clone the
sip-communicator 
> repository, commit all code to their own project
repositories and 
> start modifying the new repo to add functionality.
>
> As a result we had lots of problems. First, whenever
the students 
> would discover a problem with the code, they couldn't
really use our 
> fix since their repositories were out of sync.
>
> Then, there was also the merging problem. If we wanted
to use any of 
> their code back in SC, we had to first spend some time
making it work 
> with the latest version.
>
> And I am not even mentioning the fact that one had to
make so many 
> commits in order to upload sc that we had *four* of the
student 
> projects making the "top 10 by commits"
column on java.net for January 
> and February:
>
> http://community.java.net/projects/
toparchive.csp?year=2007&month=January
> http://community.java.net/projects
/toparchive.csp?year=2007&month=February 
>
>
> (look for the sc- prefixes)
>
> Hence, I've been thinking for some time now that we
should have a 
> project template that makes it easy to write plugins
without having to 
> clone the whole sip-communicator repository and that
would allow you 
> to stay up to date.
>
> Such a project template would have to copy the
directory structure of 
> sip-communicator (i.e. it will have to have src,
classes, lib, and 
> resources directories) but not its contents.
>
> The tricky part is that in the new project you'd still
have 
> dependencies on sip-communicator libs. The best thing
to do in order 
> to resolve that is to simply assume that the developer
using the 
> template would have sip-communicator's sources in the
same directory 
> as the template itself.
>
> For example, in a case where John Doe is working on
some project 
> called "SC BASED PROJECT", he would have the
following structure:
>
> /home/johndoe/projects
> /home/johndoe/projects/sip-communicator
> /home/johndoe/projects/sc-based-project
>
> The build.xml file of the template (sc-based-project)
would therefore 
> be able to include all necessary libs from
sip-communicator by 
> referencing them as.
>
> ../sip-communicator/lib/**/*.jar
>
> Times are more than ripe now since the google summer of
code students 
> could all use such a template.
>
> So I guess my question is: Is there a volunteer that
would like to 
> create and maintain such a java.net project that could
be used as a 
> template by new developers?
>
> I know that the irc4sc guys (http://irc4sc.dev.java.net
) are using the 
> mechanism so whoever takes that up would be able to use
their 
> structure as an example.
>
> So, any takers?
>
> Emil
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi everyone,

Did someone end up responding to Ben and this has been
continuing more 
in private, or is it still open? I read this while you guys
were talking 
about it, and Yana recently pointed me back in this
direction, but I 
haven't really understood whether or not there is a change
in how we 
should be handling our code for plug-ins. I'm new to ant and
relatively 
new to CVS and I just wanted to be clear. Could someone
please explain a 
bit what the current practice is so that I can checkout code
without 
harming whatever I've done and so that I can commit
properly? I think I 
understand, but I'd much rather be sure I have it right than

accidentally blow up repositories. Thanks for any help
anyone can offer.

Adam

Benoit Pradelle wrote:
> Hey,
>
> What has become this project ? Has a subproject been
created ? Someone 
> started to work on it ?
>
> Cheers,
> Ben
>
> Emil Ivov a écrit :
>> Hello all,
>>
>> Approximately two months ago we had some students
in the university 
>> working on plugins for sip-communicator. I had told
them at the time 
>> that for their projects they could simply clone the
sip-communicator 
>> repository, commit all code to their own project
repositories and 
>> start modifying the new repo to add functionality.
>>
>> As a result we had lots of problems. First,
whenever the students 
>> would discover a problem with the code, they
couldn't really use our 
>> fix since their repositories were out of sync.
>>
>> Then, there was also the merging problem. If we
wanted to use any of 
>> their code back in SC, we had to first spend some
time making it work 
>> with the latest version.
>>
>> And I am not even mentioning the fact that one had
to make so many 
>> commits in order to upload sc that we had *four* of
the student 
>> projects making the "top 10 by commits"
column on java.net for 
>> January and February:
>>
>> http://community.java.net/projects/
toparchive.csp?year=2007&month=January 
>>
>> http://community.java.net/projects
/toparchive.csp?year=2007&month=February 
>>
>>
>> (look for the sc- prefixes)
>>
>> Hence, I've been thinking for some time now that we
should have a 
>> project template that makes it easy to write
plugins without having 
>> to clone the whole sip-communicator repository and
that would allow 
>> you to stay up to date.
>>
>> Such a project template would have to copy the
directory structure of 
>> sip-communicator (i.e. it will have to have src,
classes, lib, and 
>> resources directories) but not its contents.
>>
>> The tricky part is that in the new project you'd
still have 
>> dependencies on sip-communicator libs. The best
thing to do in order 
>> to resolve that is to simply assume that the
developer using the 
>> template would have sip-communicator's sources in
the same directory 
>> as the template itself.
>>
>> For example, in a case where John Doe is working on
some project 
>> called "SC BASED PROJECT", he would have
the following structure:
>>
>> /home/johndoe/projects
>> /home/johndoe/projects/sip-communicator
>> /home/johndoe/projects/sc-based-project
>>
>> The build.xml file of the template
(sc-based-project) would therefore 
>> be able to include all necessary libs from
sip-communicator by 
>> referencing them as.
>>
>> ../sip-communicator/lib/**/*.jar
>>
>> Times are more than ripe now since the google
summer of code students 
>> could all use such a template.
>>
>> So I guess my question is: Is there a volunteer
that would like to 
>> create and maintain such a java.net project that
could be used as a 
>> template by new developers?
>>
>> I know that the irc4sc guys (http://irc4sc.dev.java.net
) are using 
>> the mechanism so whoever takes that up would be
able to use their 
>> structure as an example.
>>
>> So, any takers?
>>
>> Emil
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>
>>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net