[jitsi-dev] ice4j Git / Github

You are not going to like what I have to say about maven either. :slight_smile:

I'm not a fan of everything Maven does either. There are some big
differences between the Maven way of thinking (specifying exact
dependency versions) and the Debian way (using whatever dependency or
tool version is current).

However, for a simple project like ice4j, if it is intended to be
published for Maven users then it is usually convenient to just use the
pom.xml as the build system and stop maintaining build.xml. You can
have a pom.xml and build.xml in the same repository but it just creates
more work and sometimes confusion for people trying to contribute for
the first time.

Same bottom line though: what problem that *we* have is it actually solving?

Encouraging more people to choose ice4j as part of their own projects.

Having a pom.xml published everywhere with your URLs in it may also help
your search rankings.

And yes, even if we do decide to accept this, as a lead, I would
strongly object to modifying our entire directory structure around one tool.

I'm quite happy with George's solution for the directory structure

It is not just a Maven issue though - many people like to have separate
src directories for their unit tests, they don't always use the exact
Maven layout to achieve this.

路路路

On 17/01/15 12:29, Emil Ivov wrote:

You are not going to like what I have to say about maven either. :slight_smile:

Same bottom line though: what problem that *we* have is it actually solving?

(This is not specific to ice4j)
- Lack of contributors/contributions
- Ease of integration into other projects
- Keeping binaries in our lib folder
聽聽- without source attachment
聽聽- without Javadoc attachment
聽聽- largely unversioned, at best with a hash/rev. number in the commit log
- Lack of maintenance of various IDE specific project files
- The need of manually updating a bunch of projects if e.g. libjitsi is updated
- And if done properly for e.g. Jitsi/libjitsi: hot code replacement while debugging and no need to constantly run ant make anymore, speeding up development a lot by reducing cumbersome "around" tasks
- Easier (stable) releases

And yes, even if we do decide to accept this, as a lead, I would strongly
object to modifying our entire directory structure around one tool.

I made the directory change recently for sdes4j (which is still on SVN) and that was a mistake. If ice4j is on git, then changing paths is fine as git is able track them. If it stays on svn, then the paths should stay as is.

--sent from my mobile

Ingo

And yes, even if we do decide to accept this, as a lead, I would
strongly object to modifying our entire directory structure around one
tool.

I'm quite happy with George's solution for the directory structure

It is not just a Maven issue though - many people like to have separate
src directories for their unit tests, they don't always use the exact
Maven layout to achieve this.

I might be mistaken but that is the case: /trunk/src and /trunk/test.

What is missing are the typical resources directories, but
logging.properties doesn't need to be distributed for a library anyway.

Ingo

You are not going to like what I have to say about maven either. :slight_smile:

Same bottom line though: what problem that *we* have is it actually solving?

(This is not specific to ice4j)
- Lack of contributors/contributions

This is a non-argument to me. I don't see any evidence whatsoever that
ice4j contributions would change in any statistically significant way
after mavenization.

Actually contributors and contributions who do not use maven would be
in a more difficult situation. Not significantly more difficult but
since the counter argument is also marginal.

- Ease of integration into other projects

Things might be somewhat easier for people who already use maven.

I have never heard anyone complaining "OMG, ice4j is so hard to
integrate! You guys should definitely solve this"

- Keeping binaries in our lib folder

And this is a problem because?

聽聽- without source attachment
聽聽- without Javadoc attachment

If you are referring to IDEs that would automatically pick up javadoc
and sources, then yes, this is the only argument in favor of maven
that I am willing to accept.

聽聽- largely unversioned, at best with a hash/rev. number in the commit log

I don't know what this means.

- Lack of maintenance of various IDE specific project files

Same point as above and, yes, I do accept this.

- The need of manually updating a bunch of projects if e.g. libjitsi is updated

So I might be misunderstanding this but if I get it right, one would
still need to update all the projects that have ice4j as a dependency,
if only to change the version that they depend on.

Is this correct?

If so, this is a non-argument too.

- And if done properly for e.g. Jitsi/libjitsi: hot code replacement while debugging and no need to constantly run ant make anymore, speeding up development a lot by reducing cumbersome "around" tasks

I don't understand what you mean. Could you please expand?

- Easier (stable) releases

How so?

And yes, even if we do decide to accept this, as a lead, I would strongly
object to modifying our entire directory structure around one tool.

I made the directory change recently for sdes4j (which is still on SVN) and that was a mistake. If ice4j is on git, then changing paths is fine as git is able track them. If it stays on svn, then the paths should stay as is.

Well again, I am strongly opposed to this. If it is not a must then
there's probably no need to debate this either.

My driving notion in all of these discussions is that *dev tools MUST
be transparent*. People must not be forced into learning dev tool
specifics unless they explicitly need them. This should be one of the
top 3 bullet points for any tool that strives to facilitate
development. This is where git fails pitifully and changing directory
structure would also be quite a transgression for maven. Again, I am
happy that it is not a requirement.

Emil

路路路

On Sat, Jan 17, 2015 at 12:59 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

--
https://jitsi.org

Same bottom line though: what problem that *we* have is it actually
solving?

(This is not specific to ice4j)
- Lack of contributors/contributions

This is a non-argument to me. I don't see any evidence whatsoever that
ice4j contributions would change in any statistically significant way
after mavenization.

No, not for ice4j, because it is largely stable as you already said.
However, if it is possible to integrate a library by simply adding two lines
to an .xml instead of downloading it from somewhere it might lead to more
people who try. But I grant you, this is definitely not a big argument for
Maven. Using Github instead of Google Code (letting the underlying VCS aside
for the moment) surely makes a difference in visibility and ease of
accessibility.

Actually contributors and contributions who do not use maven would be
in a more difficult situation. Not significantly more difficult but
since the counter argument is also marginal.

Because they need to install Maven instead of Ant? This is only true for the
command line though. I don't know of any modern IDE that doesn't have
built-in support for opening Maven projects.

- Ease of integration into other projects

Things might be somewhat easier for people who already use maven.

I have never heard anyone complaining "OMG, ice4j is so hard to
integrate! You guys should definitely solve this"

Not ice4j, but the other projects. Ice4j could serve as an example for our
other projects because it is a small thing. And nobody says it is hard, but
it would be even easier for anyone who uses a dependency manager that uses
Maven Central as its underlying store (Maven, Ivy, AFAIK Gradle). For all
that don't use such a thing, nothing changes. They can still download
binaries and manually manage them.

- Keeping binaries in our lib folder

And this is a problem because?

It blows up the repository size. It took me the better half of a day to
clone Jitsi/libjitsi/sdes4j last August. And it is bad practice.

聽聽- without source attachment
聽聽- without Javadoc attachment

If you are referring to IDEs that would automatically pick up javadoc
and sources, then yes, this is the only argument in favor of maven
that I am willing to accept.

Yes, this is what I meant.

聽聽- largely unversioned, at best with a hash/rev. number in the commit

log

I don't know what this means.

Which exact version of jain-sip.jar and jna.jar are we currently using in
Jitsi? How much time have you just spent to find out?

- Lack of maintenance of various IDE specific project files

Same point as above and, yes, I do accept this.

Not exactly the same, but yes, similar.

- The need of manually updating a bunch of projects if e.g. libjitsi is
updated

So I might be misunderstanding this but if I get it right, one would
still need to update all the projects that have ice4j as a dependency,
if only to change the version that they depend on.

Is this correct?

No. It is possible to specify an open version number (or a range) and would
pull in the highest available version the next time the project is built.

I'm no expert on how this is usually done, but I'd only "freeze" the
imported version numbers for a stable release in separate branch.

If so, this is a non-argument too.

Even increasing a version number would IMO be better than copying locally
built binaries (e.g. I often forgot to compile against Java 1.5/1.6 causing
not so easy to find build failures later on).

- And if done properly for e.g. Jitsi/libjitsi: hot code replacement

while

debugging and no need to constantly run ant make anymore, speeding up
development a lot by reducing cumbersome "around" tasks

I don't understand what you mean. Could you please expand?

Sure. I don't know how Idea or Netbeans handles this, so I'm talking about
Eclipse now. If there are multiple projects in a workspace, you can
reference them on the classpath instead of pulling a compiled .jar in. So if
you make a change in a dependent project, there's no need to recompile a
.jar. Eclipse's Maven integration recognizes if you have a dependency in the
pom.xml as a local project and references it.
So you cannot only view the source by opening a definition, but you rather
jump to the actual source file where you can make modifications (and
potentially commit them). If hot code replace is enabled, you can even
change code while debugging.

- Easier (stable) releases

How so?

mvn release:perform

If set up properly in the pom.xml (and a local ~/.m2/settings.xml for
credentials), it performs a checkout, creates a release version number, a
tag in git/svn, uploads the artifacts to Maven central, and reverts to a new
-SNAPSHOT version number.

And yes, even if we do decide to accept this, as a lead, I would

strongly

object to modifying our entire directory structure around one tool.

I made the directory change recently for sdes4j (which is still on SVN)

and

that was a mistake. If ice4j is on git, then changing paths is fine as

git is

able track them. If it stays on svn, then the paths should stay as is.

Well again, I am strongly opposed to this. If it is not a must then
there's probably no need to debate this either.

My driving notion in all of these discussions is that *dev tools MUST
be transparent*. People must not be forced into learning dev tool
specifics unless they explicitly need them. This should be one of the
top 3 bullet points for any tool that strives to facilitate
development. This is where git fails pitifully and changing directory
structure would also be quite a transgression for maven. Again, I am
happy that it is not a requirement.

Well I agree. And I had my problems with git as well, I simply see more
advantages than disadvantages by now. And for Maven I won't say it'll be the
holy grail. I don't even know if it will be the right choice, it might even
be a mistake. But the nice thing about software is: it can easily be changed
- contrary to a house where you forgot to install tubes for the plumbing.

What I know for sure is that having ice4j on Maven central doesn't hurt us.
I'm also quite optimistic that it would reduce your problems of git messing
around with your locally modified .classpath if we would decide to move on
with other projects as well.

I really don't see how it would hurt anyone or the risks associated with it
to try Maven on ice4j.

Emil

Ingo

Same bottom line though: what problem that *we* have is it actually
solving?

(This is not specific to ice4j)
- Lack of contributors/contributions

This is a non-argument to me. I don't see any evidence whatsoever that
ice4j contributions would change in any statistically significant way
after mavenization.

No, not for ice4j, because it is largely stable as you already said.
However, if it is possible to integrate a library by simply adding two lines
to an .xml instead of downloading it from somewhere it might lead to more
people who try. But I grant you, this is definitely not a big argument for
Maven. Using Github instead of Google Code (letting the underlying VCS aside
for the moment) surely makes a difference in visibility and ease of
accessibility.

The availability of the JAR in the Maven Repository leads to more people
becoming aware of it and potentially using it in other projects. Some
of these people may troubleshoot things, submit pull requests, etc.

You don't have to build it with Maven though in order to have it
uploaded to the repository.

Actually contributors and contributions who do not use maven would be
in a more difficult situation. Not significantly more difficult but
since the counter argument is also marginal.

Because they need to install Maven instead of Ant? This is only true for the
command line though. I don't know of any modern IDE that doesn't have
built-in support for opening Maven projects.

Debian also has the Maven toolchain now. You can safely run Maven
builds without accidentally having non-free/closed-source plugins or
dependencies downloaded from the Maven repository.

- Ease of integration into other projects

Things might be somewhat easier for people who already use maven.

I have never heard anyone complaining "OMG, ice4j is so hard to
integrate! You guys should definitely solve this"

Not ice4j, but the other projects. Ice4j could serve as an example for our
other projects because it is a small thing. And nobody says it is hard, but
it would be even easier for anyone who uses a dependency manager that uses
Maven Central as its underlying store (Maven, Ivy, AFAIK Gradle). For all
that don't use such a thing, nothing changes. They can still download
binaries and manually manage them.

- Keeping binaries in our lib folder

And this is a problem because?

It blows up the repository size. It took me the better half of a day to
clone Jitsi/libjitsi/sdes4j last August. And it is bad practice.

It is definitely troublesome. Packaging also suffers because of this.

If everything is a Maven module then we can automate a lot more of the
packaging workflow. In the long run, everything becomes less tedious,
easier to patch, easier to review.

聽聽- without source attachment
聽聽- without Javadoc attachment

If you are referring to IDEs that would automatically pick up javadoc
and sources, then yes, this is the only argument in favor of maven
that I am willing to accept.

Yes, this is what I meant.

You can put that logic in build.xml. The problem is, it is tedious. I
know many large organizations that have successfully built alternatives
to Maven by using Ant+Ivy and creating build.xml templates or including
custom targets and tasks.

Such organizations are typically big enough to have a developer or even
a team of developers who just maintain their build tools.

For my own free software projects, I don't have the resources to develop
or support such a build system but I've found I can get many of the same
benefits from using Maven.

聽聽- largely unversioned, at best with a hash/rev. number in the commit

log

I don't know what this means.

You can put a task in your build.xml or Maven pom.xml to include the Git
or SVN revision into the manifest of your JARs. However, SVN revisions
are less precise than Git revisions.

Which exact version of jain-sip.jar and jna.jar are we currently using in
Jitsi? How much time have you just spent to find out?

- Lack of maintenance of various IDE specific project files

Same point as above and, yes, I do accept this.

Not exactly the same, but yes, similar.

- The need of manually updating a bunch of projects if e.g. libjitsi is
updated

So I might be misunderstanding this but if I get it right, one would
still need to update all the projects that have ice4j as a dependency,
if only to change the version that they depend on.

Is this correct?

No. It is possible to specify an open version number (or a range) and would
pull in the highest available version the next time the project is built.

I'm no expert on how this is usually done, but I'd only "freeze" the
imported version numbers for a stable release in separate branch.

Another Java project I've been working with a lot is Apache Camel. It
has many submodule JARs and each of them depends on many third party JARs.

E.g. camel-core and camel-smpp are built from the Camel repository

camel-smpp also depends on jsmpp which comes from another repository.

camel-smpp specifies the exact jsmpp version to be used.

I'd encourage you to try and checkout the source for Camel and build it,
it will take a long time but it is all automatic and you can see that no
JARs need to be embedded in the Camel repository because it can always
find everything it needs:

git clone https://git-wip-us.apache.org/repos/asf/camel.git
cd camel
mvn

You may ask: what if some dependency (e.g. jsmpp) disappears from the
central repository? Isn't it safer to keep a copy in the Camel
repository? That is a good question. Keeping a copy of the JAR in the
Camel repository is not the only answer though: you can easily build
your own local archive of JARs for Maven to fetch things from during the
build, keep that backed up just in case they go away.

If so, this is a non-argument too.

Even increasing a version number would IMO be better than copying locally
built binaries (e.g. I often forgot to compile against Java 1.5/1.6 causing
not so easy to find build failures later on).

- And if done properly for e.g. Jitsi/libjitsi: hot code replacement

while

debugging and no need to constantly run ant make anymore, speeding up
development a lot by reducing cumbersome "around" tasks

I don't understand what you mean. Could you please expand?

Sure. I don't know how Idea or Netbeans handles this, so I'm talking about
Eclipse now. If there are multiple projects in a workspace, you can
reference them on the classpath instead of pulling a compiled .jar in. So if
you make a change in a dependent project, there's no need to recompile a
.jar. Eclipse's Maven integration recognizes if you have a dependency in the
pom.xml as a local project and references it.
So you cannot only view the source by opening a definition, but you rather
jump to the actual source file where you can make modifications (and
potentially commit them). If hot code replace is enabled, you can even
change code while debugging.

- Easier (stable) releases

How so?

mvn release:perform

If set up properly in the pom.xml (and a local ~/.m2/settings.xml for
credentials), it performs a checkout, creates a release version number, a
tag in git/svn, uploads the artifacts to Maven central, and reverts to a new
-SNAPSHOT version number.

Even better:

聽聽聽聽mvn appassembler:assemble

This builds a complete tree including your dependencies and a script
that can run them. There are other permutations too for building JNLP /
WebStart projects, uber-JARs, etc.

And yes, even if we do decide to accept this, as a lead, I would

strongly

object to modifying our entire directory structure around one tool.

I made the directory change recently for sdes4j (which is still on SVN)

and

that was a mistake. If ice4j is on git, then changing paths is fine as

git is

able track them. If it stays on svn, then the paths should stay as is.

Well again, I am strongly opposed to this. If it is not a must then
there's probably no need to debate this either.

My driving notion in all of these discussions is that *dev tools MUST
be transparent*. People must not be forced into learning dev tool
specifics unless they explicitly need them. This should be one of the
top 3 bullet points for any tool that strives to facilitate
development. This is where git fails pitifully and changing directory
structure would also be quite a transgression for maven. Again, I am
happy that it is not a requirement.

Well I agree. And I had my problems with git as well, I simply see more
advantages than disadvantages by now. And for Maven I won't say it'll be the
holy grail. I don't even know if it will be the right choice, it might even
be a mistake. But the nice thing about software is: it can easily be changed
- contrary to a house where you forgot to install tubes for the plumbing.

What I know for sure is that having ice4j on Maven central doesn't hurt us.
I'm also quite optimistic that it would reduce your problems of git messing
around with your locally modified .classpath if we would decide to move on
with other projects as well.

I really don't see how it would hurt anyone or the risks associated with it
to try Maven on ice4j.

George's proposal to override Maven's preferred directory structure is
completely OK for ice4j.

If ice4j does move to Git, then somebody could actually whip up the
pom.xml on a branch for other people to try it.

However, I don't think that building ice4j with Maven is the only step
to evaluate Maven - I'd encourage you to try building some of the other
projects that use it, e.g. Apache Camel or ServiceMix use a lot of
dependency JARs.

Regards,

Daniel

路路路

On 17/01/15 16:03, Ingo Bauersachs wrote:

If we held a vote I think I wouldn't vote neither for or against mavenization.

I agree that maven has a number of advantages but my main concern is that we may end up in a complicated situation like we did with git. Besides, if somebody wants to use maven, he/she can perfectly do so without disrupting other people's workflows (which, generally speaking, is a bad thing). If enough people use maven successfully in their own local setup, then we might consider switching to it for everybody.

I don't think I've mention it here before, please forgive me if I have, but I maintain a set of scripts and some pom.xml files that mavenize most of our projects except for Jitsi (although I've done some progress there). You can find it here : https://github.com/gpolitis/jitsi-mavenization

Cheers,
George

路路路

On 17 Jan 2015, at 16:54, Daniel Pocock wrote:

On 17/01/15 16:03, Ingo Bauersachs wrote:

Same bottom line though: what problem that *we* have is it actually
solving?

(This is not specific to ice4j)
- Lack of contributors/contributions

This is a non-argument to me. I don't see any evidence whatsoever that
ice4j contributions would change in any statistically significant way
after mavenization.

No, not for ice4j, because it is largely stable as you already said.
However, if it is possible to integrate a library by simply adding two lines
to an .xml instead of downloading it from somewhere it might lead to more
people who try. But I grant you, this is definitely not a big argument for
Maven. Using Github instead of Google Code (letting the underlying VCS aside
for the moment) surely makes a difference in visibility and ease of
accessibility.

The availability of the JAR in the Maven Repository leads to more people
becoming aware of it and potentially using it in other projects. Some
of these people may troubleshoot things, submit pull requests, etc.

You don't have to build it with Maven though in order to have it
uploaded to the repository.

Actually contributors and contributions who do not use maven would be
in a more difficult situation. Not significantly more difficult but
since the counter argument is also marginal.

Because they need to install Maven instead of Ant? This is only true for the
command line though. I don't know of any modern IDE that doesn't have
built-in support for opening Maven projects.

Debian also has the Maven toolchain now. You can safely run Maven
builds without accidentally having non-free/closed-source plugins or
dependencies downloaded from the Maven repository.

- Ease of integration into other projects

Things might be somewhat easier for people who already use maven.

I have never heard anyone complaining "OMG, ice4j is so hard to
integrate! You guys should definitely solve this"

Not ice4j, but the other projects. Ice4j could serve as an example for our
other projects because it is a small thing. And nobody says it is hard, but
it would be even easier for anyone who uses a dependency manager that uses
Maven Central as its underlying store (Maven, Ivy, AFAIK Gradle). For all
that don't use such a thing, nothing changes. They can still download
binaries and manually manage them.

- Keeping binaries in our lib folder

And this is a problem because?

It blows up the repository size. It took me the better half of a day to
clone Jitsi/libjitsi/sdes4j last August. And it is bad practice.

It is definitely troublesome. Packaging also suffers because of this.

If everything is a Maven module then we can automate a lot more of the
packaging workflow. In the long run, everything becomes less tedious,
easier to patch, easier to review.

- without source attachment
- without Javadoc attachment

If you are referring to IDEs that would automatically pick up javadoc
and sources, then yes, this is the only argument in favor of maven
that I am willing to accept.

Yes, this is what I meant.

You can put that logic in build.xml. The problem is, it is tedious. I
know many large organizations that have successfully built alternatives
to Maven by using Ant+Ivy and creating build.xml templates or including
custom targets and tasks.

Such organizations are typically big enough to have a developer or even
a team of developers who just maintain their build tools.

For my own free software projects, I don't have the resources to develop
or support such a build system but I've found I can get many of the same
benefits from using Maven.

- largely unversioned, at best with a hash/rev. number in the commit

log

I don't know what this means.

You can put a task in your build.xml or Maven pom.xml to include the Git
or SVN revision into the manifest of your JARs. However, SVN revisions
are less precise than Git revisions.

Which exact version of jain-sip.jar and jna.jar are we currently using in
Jitsi? How much time have you just spent to find out?

- Lack of maintenance of various IDE specific project files

Same point as above and, yes, I do accept this.

Not exactly the same, but yes, similar.

- The need of manually updating a bunch of projects if e.g. libjitsi is
updated

So I might be misunderstanding this but if I get it right, one would
still need to update all the projects that have ice4j as a dependency,
if only to change the version that they depend on.

Is this correct?

No. It is possible to specify an open version number (or a range) and would
pull in the highest available version the next time the project is built.

I'm no expert on how this is usually done, but I'd only "freeze" the
imported version numbers for a stable release in separate branch.

Another Java project I've been working with a lot is Apache Camel. It
has many submodule JARs and each of them depends on many third party JARs.

E.g. camel-core and camel-smpp are built from the Camel repository

camel-smpp also depends on jsmpp which comes from another repository.

camel-smpp specifies the exact jsmpp version to be used.

I'd encourage you to try and checkout the source for Camel and build it,
it will take a long time but it is all automatic and you can see that no
JARs need to be embedded in the Camel repository because it can always
find everything it needs:

git clone https://git-wip-us.apache.org/repos/asf/camel.git
cd camel
mvn

You may ask: what if some dependency (e.g. jsmpp) disappears from the
central repository? Isn't it safer to keep a copy in the Camel
repository? That is a good question. Keeping a copy of the JAR in the
Camel repository is not the only answer though: you can easily build
your own local archive of JARs for Maven to fetch things from during the
build, keep that backed up just in case they go away.

If so, this is a non-argument too.

Even increasing a version number would IMO be better than copying locally
built binaries (e.g. I often forgot to compile against Java 1.5/1.6 causing
not so easy to find build failures later on).

- And if done properly for e.g. Jitsi/libjitsi: hot code replacement

while

debugging and no need to constantly run ant make anymore, speeding up
development a lot by reducing cumbersome "around" tasks

I don't understand what you mean. Could you please expand?

Sure. I don't know how Idea or Netbeans handles this, so I'm talking about
Eclipse now. If there are multiple projects in a workspace, you can
reference them on the classpath instead of pulling a compiled .jar in. So if
you make a change in a dependent project, there's no need to recompile a
.jar. Eclipse's Maven integration recognizes if you have a dependency in the
pom.xml as a local project and references it.
So you cannot only view the source by opening a definition, but you rather
jump to the actual source file where you can make modifications (and
potentially commit them). If hot code replace is enabled, you can even
change code while debugging.

- Easier (stable) releases

How so?

mvn release:perform

If set up properly in the pom.xml (and a local ~/.m2/settings.xml for
credentials), it performs a checkout, creates a release version number, a
tag in git/svn, uploads the artifacts to Maven central, and reverts to a new
-SNAPSHOT version number.

Even better:

mvn appassembler:assemble

This builds a complete tree including your dependencies and a script
that can run them. There are other permutations too for building JNLP /
WebStart projects, uber-JARs, etc.

And yes, even if we do decide to accept this, as a lead, I would

strongly

object to modifying our entire directory structure around one tool.

I made the directory change recently for sdes4j (which is still on SVN)

and

that was a mistake. If ice4j is on git, then changing paths is fine as

git is

able track them. If it stays on svn, then the paths should stay as is.

Well again, I am strongly opposed to this. If it is not a must then
there's probably no need to debate this either.

My driving notion in all of these discussions is that *dev tools MUST
be transparent*. People must not be forced into learning dev tool
specifics unless they explicitly need them. This should be one of the
top 3 bullet points for any tool that strives to facilitate
development. This is where git fails pitifully and changing directory
structure would also be quite a transgression for maven. Again, I am
happy that it is not a requirement.

Well I agree. And I had my problems with git as well, I simply see more
advantages than disadvantages by now. And for Maven I won't say it'll be the
holy grail. I don't even know if it will be the right choice, it might even
be a mistake. But the nice thing about software is: it can easily be changed
- contrary to a house where you forgot to install tubes for the plumbing.

What I know for sure is that having ice4j on Maven central doesn't hurt us.
I'm also quite optimistic that it would reduce your problems of git messing
around with your locally modified .classpath if we would decide to move on
with other projects as well.

I really don't see how it would hurt anyone or the risks associated with it
to try Maven on ice4j.

George's proposal to override Maven's preferred directory structure is
completely OK for ice4j.

If ice4j does move to Git, then somebody could actually whip up the
pom.xml on a branch for other people to try it.

However, I don't think that building ice4j with Maven is the only step
to evaluate Maven - I'd encourage you to try building some of the other
projects that use it, e.g. Apache Camel or ServiceMix use a lot of
dependency JARs.

Regards,

Daniel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev