[jitsi-dev] Move IDE project files


#1

Hey

I thought of moving the IDE project files to the locations where they are expected by the respective IDE (root folder for Eclipse, .nbproject for Netbeans, whatever for Idea once it comes).

It is IMHO very unlikely that this will cause conflicts, but it would eliminate the manual patching of the locally copied files when e.g. the classpath changes. It would also make the import of the project for new users easier.

Any objections/comments to that?

Regards,
Ingo


#2

Hi,

I think its ok. Just one think that comes to my mind is updating while
project is open. Not sure how eclipse handles this. The Idea detects
it and offer to reload the project. Currently cannot remember how
netbeans reacts on project files update.
The good thing about Idea is that it can use the eclipse classpath
file and once it is moved where it is supposed to be will be easier to
add and project configuration for Idea.

Cheers
damencho

···

On Tue, Nov 29, 2011 at 12:38 PM, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:

Hey

I thought of moving the IDE project files to the locations where they are expected by the respective IDE (root folder for Eclipse, .nbproject for Netbeans, whatever for Idea once it comes).

It is IMHO very unlikely that this will cause conflicts, but it would eliminate the manual patching of the locally copied files when e.g. the classpath changes. It would also make the import of the project for new users easier.

Any objections/comments to that?

Regards,
Ingo


#3

+1

···

2011/11/29 Bauersachs Ingo <ingo.bauersachs@fhnw.ch>:

Hey

I thought of moving the IDE project files to the locations where they are expected by the respective IDE (root folder for Eclipse, .nbproject for Netbeans, whatever for Idea once it comes).

It is IMHO very unlikely that this will cause conflicts, but it would eliminate the manual patching of the locally copied files when e.g. the classpath changes. It would also make the import of the project for new users easier.

Any objections/comments to that?

Regards,
Ingo


#4

Hey Ingo,

I also agree.

Cheers,
Yana

···

On Nov 29, 2011, at 11:38 AM, Bauersachs Ingo wrote:

Hey

I thought of moving the IDE project files to the locations where they are expected by the respective IDE (root folder for Eclipse, .nbproject for Netbeans, whatever for Idea once it comes).

It is IMHO very unlikely that this will cause conflicts, but it would eliminate the manual patching of the locally copied files when e.g. the classpath changes. It would also make the import of the project for new users easier.

Any objections/comments to that?

Regards,
Ingo


#5

На 29.11.11 11:38, Bauersachs Ingo написа:

Hey

I thought of moving the IDE project files to the locations where they are expected by the respective IDE (root folder for Eclipse, .nbproject for Netbeans, whatever for Idea once it comes).

It is IMHO very unlikely that this will cause conflicts, but it would eliminate the manual patching of the locally copied files when e.g. the classpath changes. It would also make the import of the project for new users easier.

Any objections/comments to that?

Looks like we have rough consensus.

I suppose we can go ahead then. Feel free to entirely remove the ide dir.

Cheers,
Emil

···

Regards,
Ingo

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#6

As far as my experience with Eclipse goes, the revision control system
integration in Eclipse works on the workspace abstraction of the file
system which includes the .project and .classpath files and Eclipse
does take the modifications into account.

···

2011/11/29 Damian Minkov <damencho@jitsi.org>:

I think its ok. Just one think that comes to my mind is updating while
project is open. Not sure how eclipse handles this.


#7

Hi,

there is currently an entry in .classpath which I think have to be
removed, its the jdk setting. Isn't it that if the property is missing
the eclipse ide will chose its default setting for jdk? WDYT?
The property is:

<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/>

It was missing in previous version of .classpath, I think.

I wanted to commit Intellij Idea project file, but as this setting
exists, every time you open the project it complains about missing
jdk. That's because the Idea project file is set to use eclipse files.
But reusing those files avoids duplication of library description.

Regards
damencho

···

On Tue, Nov 29, 2011 at 3:13 PM, Emil Ivov <emcho@jitsi.org> wrote:

На 29.11.11 11:38, Bauersachs Ingo написа:

Hey

I thought of moving the IDE project files to the locations where they are expected by the respective IDE (root folder for Eclipse, .nbproject for Netbeans, whatever for Idea once it comes).

It is IMHO very unlikely that this will cause conflicts, but it would eliminate the manual patching of the locally copied files when e.g. the classpath changes. It would also make the import of the project for new users easier.

Any objections/comments to that?

Looks like we have rough consensus.

I suppose we can go ahead then. Feel free to entirely remove the ide dir.

Cheers,
Emil

Regards,
Ingo

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#8

Hey

It was slightly different in the previous template:
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> Which takes the default JRE.

The addition of "/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5" signals to select a Java 1.5 JRE/JDK. If no matching JRE/JDK5 is installed, then it still selects the JRE6 (or simply the best match it can find from the list of installed JREs), so I thought it doesn't hurt.

But still, the missing JDK warning from IntelliJ is IMHO correct: If we target Java 1.5, then we should compile against it. Otherwise it leads into believing that an API can be used because of the 1.6 JDK and Javadoc while in fact it cannot (e.g. the JDialog constructor bug which accepts null in 1.6 but doesn't in 1.5).

So my vote would be to leave it, but I'd like to hear the opinion of others.

Regards,
Ingo

···

-----Original Message-----
From: damencho@damencho.com [mailto:damencho@damencho.com] On Behalf Of
Damian Minkov
Sent: Mittwoch, 30. November 2011 10:28
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: Move IDE project files

Hi,

there is currently an entry in .classpath which I think have to be
removed, its the jdk setting. Isn't it that if the property is missing
the eclipse ide will chose its default setting for jdk? WDYT?
The property is:

<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.
ui.launcher.StandardVMType/J2SE-1.5"/>

It was missing in previous version of .classpath, I think.

I wanted to commit Intellij Idea project file, but as this setting
exists, every time you open the project it complains about missing
jdk. That's because the Idea project file is set to use eclipse files.
But reusing those files avoids duplication of library description.

Regards
damencho

On Tue, Nov 29, 2011 at 3:13 PM, Emil Ivov <emcho@jitsi.org> wrote:
> На 29.11.11 11:38, Bauersachs Ingo написа:
>> Hey
>>
>> I thought of moving the IDE project files to the locations where they are
expected by the respective IDE (root folder for Eclipse, .nbproject for
Netbeans, whatever for Idea once it comes).
>>
>> It is IMHO very unlikely that this will cause conflicts, but it would
eliminate the manual patching of the locally copied files when e.g. the
classpath changes. It would also make the import of the project for new users
easier.
>>
>> Any objections/comments to that?
>
> Looks like we have rough consensus.
>
> I suppose we can go ahead then. Feel free to entirely remove the ide dir.
>
> Cheers,
> Emil
>
>>
>> Regards,
>> Ingo
>>
>
> --
> Emil Ivov, Ph.D. 67000 Strasbourg,
> Project Lead France
> Jitsi
> emcho@jitsi.org PHONE: +33.1.77.62.43.30
> http://jitsi.org FAX: +33.1.77.62.47.31
>


#9

It was slightly different in the previous template:
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> Which takes the default JRE.

The addition of "/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5" signals to select a Java 1.5 JRE/JDK. If no matching JRE/JDK5 is installed, then it still selects the JRE6 (or simply the best match it can find from the list of installed JREs), so I thought it doesn't hurt.

Well, doesn't the fact that Eclipse falls back to 1.6 (or the best
available match) for J2SE-1.5 in the absence of a perfect match defeat
the usefulness of the addition in a way?

But still, the missing JDK warning from IntelliJ is IMHO correct: If we target Java 1.5, then we should compile against it. Otherwise it leads into believing that an API can be used because of the 1.6 JDK and Javadoc while in fact it cannot (e.g. the JDialog constructor bug which accepts null in 1.6 but doesn't in 1.5).

I still have to install a perfect match for J2SE-1.5 in order to make
use of the automatic protection from using unavailable API.

In light of the problem that it creates for IntelliJ IDEA, I'd vote
the addition down because I find the line between its advantages and
disadvantages vague.

···

2011/11/30 Bauersachs Ingo <ingo.bauersachs@fhnw.ch>:


#10

Hey

The addition of
"/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5" signals
to select a Java 1.5 JRE/JDK. If no matching JRE/JDK5 is installed, then it
still selects the JRE6 (or simply the best match it can find from the list of
installed JREs), so I thought it doesn't hurt.

Well, doesn't the fact that Eclipse falls back to 1.6 (or the best
available match) for J2SE-1.5 in the absence of a perfect match defeat
the usefulness of the addition in a way?

Not when you have a JDK5 installed, which I have to avoid introducing further 1.6 related bugs.

But still, the missing JDK warning from IntelliJ is IMHO correct: If we
target Java 1.5, then we should compile against it. Otherwise it leads into
believing that an API can be used because of the 1.6 JDK and Javadoc while in
fact it cannot (e.g. the JDialog constructor bug which accepts null in 1.6
but doesn't in 1.5).

I still have to install a perfect match for J2SE-1.5 in order to make
use of the automatic protection from using unavailable API.

IMO that should be done as long as we're targeting 1.5...

In light of the problem that it creates for IntelliJ IDEA, I'd vote
the addition down because I find the line between its advantages and
disadvantages vague.

If we once start to clean up our libraries and e.g. use Ivy or Maven as suggested by Thomas Koch (and required for a "real" Debian package), then entries like
  <classpathentry kind="con" path="org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/?ivyXmlPath=ivy.xml&amp;confs=*"/>
  <classpathentry kind="con" path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/>
Will most probably be added to the .classpath file. How is IntelliJ going to handle these?

Regards,
Ingo


#11

Hi,

···

On Wed, Nov 30, 2011 at 12:40 PM, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:

Hey

The addition of
"/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5" signals
to select a Java 1.5 JRE/JDK. If no matching JRE/JDK5 is installed, then it
still selects the JRE6 (or simply the best match it can find from the list of
installed JREs), so I thought it doesn't hurt.

Well, doesn't the fact that Eclipse falls back to 1.6 (or the best
available match) for J2SE-1.5 in the absence of a perfect match defeat
the usefulness of the addition in a way?

Not when you have a JDK5 installed, which I have to avoid introducing further 1.6 related bugs.

But still, the missing JDK warning from IntelliJ is IMHO correct: If we
target Java 1.5, then we should compile against it. Otherwise it leads into
believing that an API can be used because of the 1.6 JDK and Javadoc while in
fact it cannot (e.g. the JDialog constructor bug which accepts null in 1.6
but doesn't in 1.5).

I still have to install a perfect match for J2SE-1.5 in order to make
use of the automatic protection from using unavailable API.

IMO that should be done as long as we're targeting 1.5...

In light of the problem that it creates for IntelliJ IDEA, I'd vote
the addition down because I find the line between its advantages and
disadvantages vague.

If we once start to clean up our libraries and e.g. use Ivy or Maven as suggested by Thomas Koch (and required for a "real" Debian package), then entries like
<classpathentry kind="con" path="org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/?ivyXmlPath=ivy.xml&amp;confs=*"/>
<classpathentry kind="con" path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/>
Will most probably be added to the .classpath file. How is IntelliJ going to handle these?

I don't know :slight_smile: I saw it has support for Ivy, suppose it will work.

Regards
damencho


#12

I don't know :slight_smile: I saw it has support for Ivy, suppose it will work.

Well support for Ivy doesn't necessarily mean that it has support for an IvyDE (the Ivy plugin for Eclipse) classpathcontainer-entry... :slight_smile:

I don't want to start a war here, but just out of curiosity: How does IntelliJ handle the classpath if doesn't reference the Eclipse file? I'm thinking about separating those, and once Ivy would be in place, manual changes to the CP should become extremely rare.

Regards,
Ingo


#13

Hi again,

I don't know :slight_smile: I saw it has support for Ivy, suppose it will work.

Well support for Ivy doesn't necessarily mean that it has support for an IvyDE (the Ivy plugin for Eclipse) classpathcontainer-entry... :slight_smile:

I don't want to start a war here, but just out of curiosity: How does IntelliJ handle the classpath if doesn't reference the Eclipse file? I'm thinking about separating those, and once Ivy would be in place, manual changes to the CP should become extremely rare.

Well it embeds those libraries into project file. Initially I thought
it is good to have an Idea project file which make use of the eclipse
classpath description, then I was using the old classpath files
without the new property. There is no problem in embedding the
libraries there, its still xml and can be edited by anyone.
By the way doesn't eclipse has setting for language level?
And one more thing, what is the default name of the jdk-s in eclipse
when you import it?

Regards
damencho

···

On Wed, Nov 30, 2011 at 1:01 PM, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:


#14

Just for the record. I was OK with bringing the project files to root
but I don't think this is a good think for major shifts like using Ivy
for example. We have too many things going.

Could we please just keep our previous setup for the time being?

Thanks,
Emil

···

On 30.11.11 12:01, Bauersachs Ingo wrote:

I don't know :slight_smile: I saw it has support for Ivy, suppose it will work.

Well support for Ivy doesn't necessarily mean that it has support for an IvyDE (the Ivy plugin for Eclipse) classpathcontainer-entry... :slight_smile:

I don't want to start a war here, but just out of curiosity: How does IntelliJ handle the classpath if doesn't reference the Eclipse file? I'm thinking about separating those, and once Ivy would be in place, manual changes to the CP should become extremely rare.

Regards,
Ingo

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#15

Just for the record. I was OK with bringing the project files to root
but I don't think this is a good think for major shifts like using Ivy
for example. We have too many things going.

That Ivy stuff was hypothetical thinking, I don't plan to do that anytime soon.

Could we please just keep our previous setup for the time being?

Sure. Then it comes back to: Should IntelliJ users install a JDK5 or remove the line. I won't decide that as I can always do a "git update-index --assume-unchanged .classpath" and configure my own copy :slight_smile:

Regards,
Ingo


#16

Hi again,

···

On Wed, Nov 30, 2011 at 2:32 PM, Emil Ivov <emcho@jitsi.org> wrote:

Could we please just keep our previous setup for the time being?

Well I have missed this one from yesterdays conversation. I've updated
the classpath file to previous state and have committed it.

Sorry for the noise
damencho


#17

Hi,

ok I've just committed the idea files, without changing the eclipse
stuff. So if any other Idea user comes up can give a different opinion
or proposal :slight_smile:

Cheers
damencho

···

On Wed, Nov 30, 2011 at 3:07 PM, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:

Just for the record. I was OK with bringing the project files to root
but I don't think this is a good think for major shifts like using Ivy
for example. We have too many things going.

That Ivy stuff was hypothetical thinking, I don't plan to do that anytime soon.

Could we please just keep our previous setup for the time being?

Sure. Then it comes back to: Should IntelliJ users install a JDK5 or remove the line. I won't decide that as I can always do a "git update-index --assume-unchanged .classpath" and configure my own copy :slight_smile:

Regards,
Ingo


#18

Well, one JRE must stay there or the file is invalid for Eclipse, e.g. for the default Workspace JRE:
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>

Ingo

···

-----Original Message-----
From: damencho@damencho.com [mailto:damencho@damencho.com] On Behalf Of
Damian Minkov
Sent: Donnerstag, 1. Dezember 2011 11:52
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: Move IDE project files

Hi again,

On Wed, Nov 30, 2011 at 2:32 PM, Emil Ivov <emcho@jitsi.org> wrote:
> Could we please just keep our previous setup for the time being?

Well I have missed this one from yesterdays conversation. I've updated
the classpath file to previous state and have committed it.

Sorry for the noise
damencho


#19

Wasn't this the format of the file we previously had in ide folder,
without any such setting?

···

On Thu, Dec 1, 2011 at 12:53 PM, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:

Well, one JRE must stay there or the file is invalid for Eclipse, e.g. for the default Workspace JRE:
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>

Ingo

-----Original Message-----
From: damencho@damencho.com [mailto:damencho@damencho.com] On Behalf Of
Damian Minkov
Sent: Donnerstag, 1. Dezember 2011 11:52
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: Move IDE project files

Hi again,

On Wed, Nov 30, 2011 at 2:32 PM, Emil Ivov <emcho@jitsi.org> wrote:
> Could we please just keep our previous setup for the time being?

Well I have missed this one from yesterdays conversation. I've updated
the classpath file to previous state and have committed it.

Sorry for the noise
damencho


#20

Yeah, have looked in diff history but have missed and this one. Sorry
once again, and thanks Ingo for the quick note.

···

On Thu, Dec 1, 2011 at 1:00 PM, Damian Minkov <damencho@jitsi.org> wrote:

Wasn't this the format of the file we previously had in ide folder,
without any such setting?

On Thu, Dec 1, 2011 at 12:53 PM, Bauersachs Ingo > <ingo.bauersachs@fhnw.ch> wrote:

Well, one JRE must stay there or the file is invalid for Eclipse, e.g. for the default Workspace JRE:
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>

Ingo

-----Original Message-----
From: damencho@damencho.com [mailto:damencho@damencho.com] On Behalf Of
Damian Minkov
Sent: Donnerstag, 1. Dezember 2011 11:52
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: Move IDE project files

Hi again,

On Wed, Nov 30, 2011 at 2:32 PM, Emil Ivov <emcho@jitsi.org> wrote:
> Could we please just keep our previous setup for the time being?

Well I have missed this one from yesterdays conversation. I've updated
the classpath file to previous state and have committed it.

Sorry for the noise
damencho