Discussion:
Restlet Framework 2.2 - Build issues and Eclipse/OSGi development
(too old to reply)
Jerome Louvel
2012-04-27 07:05:43 UTC
Permalink
Hi all,



We've been discussing internally and separately with several contributors
regarding the build issues occurring on the master branch in GitHub,
especially with Eclipse 3.7. I'd like open up the discussion in our
developers list and take this opportunity to clarify our goals for next 2.2
version and better coordinate our efforts and expectations :



1) Repair the Eclipse PDE build



The current/historical way we use to build from Eclipse is through OSGi
bundles. If you install the PDE plugins (or choose the proper Eclipse
editions), this should work by default as explained here (needs some
update): http://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html



For version 2.2, we are trying to migrate to the latest Eclipse 3.7 version,
which now includes Maven support by default (built-in m2e plugin). The first
step I've been trying to accomplish is to ensure that the pom.xml files
present in the module directories don't conflict with the usual Eclipse/PDE
build process.



To use Eclipse/PDE build, you either need the "Eclipse Classic" edition
which comes with PDE bundled, or to install PDE on top of the lighter
"Eclipse IDE for Java" edition. Then, if you import both the modules and the
libraries project as explained in the wiki, you should see the build work
just fine.



We do have remaining issues with OAuth, OpenID extensions, as well as the
examples project that need to be fixed. I'm a bit stuck on this so any help
is welcome. Maybe Kristoffer and/or Martin can help for the OAuth and OpenID
extensions?



2) Make the m2e build work



For 2.2, we would like the master to work with m2e
<http://www.eclipse.org/m2e/> as well (new name for m2eclipse), as it is
now bundled by default since Eclipse 3.7 (IDE for Java).



Note that currently, our POM.xml files are not manually edited but instead
generated by our forge (ant scripts) from our own module.xml files. This was
necessary in order to support multi-edition builds and distributions in
various channels (Eclipse update site, Maven update site).



So, in addition to adjusting the .project and .classpath files, we should
ensure that we can (re-)generate the proper pom.xml files. Shaun Elliot has
offered to help on that front and other contributions will be welcome, but
we need to be careful when contributing changes to Eclipse project and pom
files.



3) Ensure compatibility when both PDE build and m2e are active



Finally, we should try to make the build with both pde and m2e work at the
same time in case the developers needs to develop in PDE/OSGi mode.
Currently, I see no way to fully turn off m2e for a workspace or a project,
which is annoying. There is probably a solution I'm not aware of.



The minimum is to ensure that there is no conflict and the binaries are
produced in separate directories (bin for PDE and target/classes for m2e).



4) Integrate the org.restlet.ext.osgi extension



Once the previous steps are complete, at least the first ones, we'll start
integrating the contribution from Bryan Hunt and others currently located
at:

https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/



This will allow fully dynamic usage of Restlet thanks to OSGi, such as
adding new applications or resources on the fly.



Best regards,

Jerome

--

<http://www.restlet.com/> http://www.restlet.com

<http://twitter.com/#!/jlouvel> http://twitter.com/#!/jlouvel

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2953671
Shaun Elliott
2012-04-27 15:56:01 UTC
Permalink
All,

Some general thoughts\notes:

1) It seems we have 2 build systems at play here. One being OSGi via Eclipse PDE tooling and the other being Maven.
2) Because of this there are some inconsistencies that make the projects not necessarily standard. For example, (maven standard) to use src/main/resources, src/main/java, etc folder structure.
3) The m2Eclipse additions to the relevant Eclipse project files (.classpath, .project).

It seems to me that tycho (http://www.sonatype.org/tycho) might be a good fit here? It would allow for BOTH OSGi and maven builds, and might fit nicely into Eclipse. However, I am unsure of the effort involved in converting over.

Personally, I'd be good with simply having Restlet work with m2E "out of the box", eg: freshly checked out from git, which, I don't think is alot of effort, but I thought I'd mention tycho as it might cleanup the overall process.

Thoughts?

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2954488
David Fogel
2012-05-01 18:27:58 UTC
Permalink
Hi Jerome, all-

I'm not a big fan of Maven, and so I'd favor a build system that
didn't depend on it. That said, the PDE is a major pain in the ass
for many projects. For many years, we used PDE for all our projects
(which are all built as OSGi bundles), including internal builds of
Restlet, but a while ago we finally got so frustrated with the PDE
that we completely reworked our project and build systems. We
initially tried to use Bndtools, and maybe that would have worked if
we'd stuck with it, but at the time it wasn't well documented. That
might be worth looking into for Restlet.

What we ended up with for our own stuff is a system built around
Gradle ( http://gradle.org/ ). Gradle is similar to Maven in some
ways, but it is super flexible, and you write your build scripts in
groovy/java instead of XML. Gradle is extremely well documented, which
I think is a major argument in its favor over Maven, all technical
differences aside.

There are some pretty big incompatibilities between the way PDE works
and most other build systems, which makes it hard for a single project
to play well with both. In particular, whereas PDE uses OSGi metadata
in the Manifest files to control the build, most other build systems
work by putting that metadata in a build/config file and then
generating the bundle Manifest file during the build process.
Projects that work with both can end up with two different manifest
files, only one of which is used in the final artifact. While the PDE
approach is arguably more consistent with the way OSGi dependencies
work, the PDE environment has never really broken away from its more
narrow focus of building eclipse plugins, is inflexible, and is hard
to extend for more complex projects.

-Dave Fogel

On Fri, Apr 27, 2012 at 3:05 AM, Jerome Louvel
Post by Jerome Louvel
Hi all,
We’ve been discussing internally and separately with several contributors
regarding the build issues occurring on the master branch in GitHub,
especially with Eclipse 3.7. I’d like open up the discussion in our
developers list and take this opportunity to clarify our goals for next 2.2
1) Repair the Eclipse PDE build
The current/historical way we use to build from Eclipse is through OSGi
bundles. If you install the PDE plugins (or choose the proper Eclipse
editions), this should work by default as explained here (needs some
update): http://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html
For version 2.2, we are trying to migrate to the latest Eclipse 3.7 version,
which now includes Maven support by default (built-in m2e plugin). The first
step I’ve been trying to accomplish is to ensure that the pom.xml files
present in the module directories don’t conflict with the usual Eclipse/PDE
build process.
To use Eclipse/PDE build, you either need the “Eclipse Classic” edition
which comes with PDE bundled, or to install PDE on top of the lighter
“Eclipse IDE for Java” edition. Then, if you import both the modules and the
libraries project as explained in the wiki, you should see the build work
just fine.
We do have remaining issues with OAuth, OpenID extensions, as well as the
examples project that need to be fixed. I’m a bit stuck on this so any help
is welcome. Maybe Kristoffer and/or Martin can help for the OAuth and OpenID
extensions?
2) Make the m2e build work
For 2.2, we would like the master to work with m2e as well (new name for
m2eclipse), as it is now bundled by default since Eclipse 3.7 (IDE for
Java).
Note that currently, our POM.xml files are not manually edited but instead
generated by our forge (ant scripts) from our own module.xml files. This was
necessary in order to support multi-edition builds and distributions in
various channels (Eclipse update site, Maven update site).
So, in addition to adjusting the .project and .classpath files, we should
ensure that we can (re-)generate the proper pom.xml files. Shaun Elliot has
offered to help on that front and other contributions will be welcome, but
we need to be careful when contributing changes to Eclipse project and pom
files.
3) Ensure compatibility when both PDE build and m2e are active
Finally, we should try to make the build with both pde and m2e work at the
same time in case the developers needs to develop in PDE/OSGi mode.
Currently, I see no way to fully turn off m2e for a workspace or a project,
which is annoying. There is probably a solution I’m not aware of.
The minimum is to ensure that there is no conflict and the binaries are
produced in separate directories (bin for PDE and target/classes for m2e).
4) Integrate the org.restlet.ext.osgi extension
Once the previous steps are complete, at least the first ones, we’ll start
integrating the contribution from Bryan Hunt and others currently located
https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/
This will allow fully dynamic usage of Restlet thanks to OSGi, such as
adding new applications or resources on the fly.
Best regards,
Jerome
--
http://www.restlet.com
http://twitter.com/#!/jlouvel
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2956647
Tal Liron
2012-05-01 18:44:27 UTC
Permalink
<html style="direction: ltr;">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="UTF-8" text="#000000"
bgcolor="#FFFFFF">
<p>I have to agree with David on much of this.<br>
<br>
1) Maven is a headache. It's important to support Maven
repositories, but it's possible to do so by creating POMs that
simply attach already-built Jars, such that Maven does not become
a requirement for those susceptible to headaches. I think Restlet
has also suffered from this, as small regressions in POMs
continuously frustrate would-be contributors. Maven is finicky.
Also, as David points out, there are other tools that support
Maven repositories. Gradle, or even use Ivy directly (the tool on
which Gradle is based) from Ant tasks. Point being: you don't need
Maven for Maven.<br>
<br>
2) If Maven is a headache, PDE is a disaster. Since Restlet does
not depend on Eclipse/Equinox, this dependency always struck me as
odd. It's quite possible to build OSGi without any of that; and,
again, like Maven, not everybody needs or wants or likes OSGi.
What are you going to do if you ever want to support Jigsaw? Wait
for it to come to Eclipse?<br>
<br>
I'm personally always in favor of dumbing things down: Ant scripts
are fairly easy to read (they are scripts) and anyone can join in
the fun. I understand that Restlet targets enterprise customers,
but the library itself, even with its ecology of plugins, is
actually quite minimal and light. Somehow over the years the build
process has become very complicated. If you're stuck, I think that
instead of trying to fix this massive structure, it may be worth
rethinking the whole scheme.<br>
<br>
I think it's furthermore worth thinking of an alternative to the
way editions are compiled now, using a preprocessor. This again
makes Restlet a very quirky project, where its source code is not
in fact source code. It's hard to think of a solution that doesn't
present further problems, but this current solution is especially
difficult to work with.<br>
<br>
-Tal<br>
</p>
<br>
On 05/01/2012 01:27 PM, David Fogel wrote:
<blockquote
cite="mid:CAKtT4xMXrFPSf8TzFpbK3fc+hPsKu3P_KFGRyvEXwVR_T=5cGg-***@public.gmane.orgl.com"
type="cite">
<pre wrap="">Hi Jerome, all-

I'm not a big fan of Maven, and so I'd favor a build system that
didn't depend on it. That said, the PDE is a major pain in the ass
for many projects. For many years, we used PDE for all our projects
(which are all built as OSGi bundles), including internal builds of
Restlet, but a while ago we finally got so frustrated with the PDE
that we completely reworked our project and build systems. We
initially tried to use Bndtools, and maybe that would have worked if
we'd stuck with it, but at the time it wasn't well documented. That
might be worth looking into for Restlet.

What we ended up with for our own stuff is a system built around
Gradle ( <a class="moz-txt-link-freetext" href="http://gradle.org/">http://gradle.org/</a> ). Gradle is similar to Maven in some
ways, but it is super flexible, and you write your build scripts in
groovy/java instead of XML. Gradle is extremely well documented, which
I think is a major argument in its favor over Maven, all technical
differences aside.

There are some pretty big incompatibilities between the way PDE works
and most other build systems, which makes it hard for a single project
to play well with both. In particular, whereas PDE uses OSGi metadata
in the Manifest files to control the build, most other build systems
work by putting that metadata in a build/config file and then
generating the bundle Manifest file during the build process.
Projects that work with both can end up with two different manifest
files, only one of which is used in the final artifact. While the PDE
approach is arguably more consistent with the way OSGi dependencies
work, the PDE environment has never really broken away from its more
narrow focus of building eclipse plugins, is inflexible, and is hard
to extend for more complex projects.

-Dave Fogel

On Fri, Apr 27, 2012 at 3:05 AM, Jerome Louvel <a class="moz-txt-link-rfc2396E" href="mailto:jerome.louvel-s0N/***@public.gmane.org">&lt;jerome.louvel-s0N/***@public.gmane.org&gt;</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,



We’ve been discussing internally and separately with several contributors
regarding the build issues occurring on the master branch in GitHub,
especially with Eclipse 3.7. I’d like open up the discussion in our
developers list and take this opportunity to clarify our goals for next 2.2
version and better coordinate our efforts and expectations :



1) Repair the Eclipse PDE build



The current/historical way we use to build from Eclipse is through OSGi
bundles. If you install the PDE plugins (or choose the proper Eclipse
editions), this should work by default as explained here (needs some
update): <a class="moz-txt-link-freetext" href="http://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html">http://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html</a>



For version 2.2, we are trying to migrate to the latest Eclipse 3.7 version,
which now includes Maven support by default (built-in m2e plugin). The first
step I’ve been trying to accomplish is to ensure that the pom.xml files
present in the module directories don’t conflict with the usual Eclipse/PDE
build process.



To use Eclipse/PDE build, you either need the “Eclipse Classic” edition
which comes with PDE bundled, or to install PDE on top of the lighter
“Eclipse IDE for Java” edition. Then, if you import both the modules and the
libraries project as explained in the wiki, you should see the build work
just fine.



We do have remaining issues with OAuth, OpenID extensions, as well as the
examples project that need to be fixed. I’m a bit stuck on this so any help
is welcome. Maybe Kristoffer and/or Martin can help for the OAuth and OpenID
extensions?



2) Make the m2e build work



For 2.2, we would like the master to work with m2e as well (new name for
m2eclipse), as it is now bundled by default since Eclipse 3.7 (IDE for
Java).



Note that currently, our POM.xml files are not manually edited but instead
generated by our forge (ant scripts) from our own module.xml files. This was
necessary in order to support multi-edition builds and distributions in
various channels (Eclipse update site, Maven update site).



So, in addition to adjusting the .project and .classpath files, we should
ensure that we can (re-)generate the proper pom.xml files. Shaun Elliot has
offered to help on that front and other contributions will be welcome, but
we need to be careful when contributing changes to Eclipse project and pom
files.



3) Ensure compatibility when both PDE build and m2e are active



Finally, we should try to make the build with both pde and m2e work at the
same time in case the developers needs to develop in PDE/OSGi mode.
Currently, I see no way to fully turn off m2e for a workspace or a project,
which is annoying. There is probably a solution I’m not aware of.



The minimum is to ensure that there is no conflict and the binaries are
produced in separate directories (bin for PDE and target/classes for m2e).



4) Integrate the org.restlet.ext.osgi extension



Once the previous steps are complete, at least the first ones, we’ll start
integrating the contribution from Bryan Hunt and others currently located
at:

<a class="moz-txt-link-freetext" href="https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/">https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/</a>



This will allow fully dynamic usage of Restlet thanks to OSGi, such as
adding new applications or resources on the fly.



Best regards,

Jerome

--

<a class="moz-txt-link-freetext" href="http://www.restlet.com">http://www.restlet.com</a>

<a class="moz-txt-link-freetext" href="http://twitter.com/#!/jlouvel">http://twitter.com/#!/jlouvel</a>


</pre>
</blockquote>
<pre wrap="">
------------------------------------------------------
<a class="moz-txt-link-freetext" href="http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=2956647">http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=2956647</a>
</pre>
</blockquote>
</body>
</html>

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2956650
Tim Peierls
2012-05-01 20:53:53 UTC
Permalink
Agree with David and Tal in general. (Full disclosure: I'm an Ant/Ivy user.)

Possible point of divergence is that I don't see how to avoid the
preprocessor-based approach to editions, though I do see the problems with
not having a single body of pure Java source. I wonder how much of the
alternative compilation could be handled with run-time constants and
if-else (trusting to modern JVMs to optimize away the unused branches) and
stub libraries.

--tim
Post by Tal Liron
<html style="direction: ltr;">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="UTF-8" text="#000000"
bgcolor="#FFFFFF">
<p>I have to agree with David on much of this.<br>
<br>
1) Maven is a headache. It's important to support Maven
repositories, but it's possible to do so by creating POMs that
simply attach already-built Jars, such that Maven does not become
a requirement for those susceptible to headaches. I think Restlet
has also suffered from this, as small regressions in POMs
continuously frustrate would-be contributors. Maven is finicky.
Also, as David points out, there are other tools that support
Maven repositories. Gradle, or even use Ivy directly (the tool on
which Gradle is based) from Ant tasks. Point being: you don't need
Maven for Maven.<br>
<br>
2) If Maven is a headache, PDE is a disaster. Since Restlet does
not depend on Eclipse/Equinox, this dependency always struck me as
odd. It's quite possible to build OSGi without any of that; and,
again, like Maven, not everybody needs or wants or likes OSGi.
What are you going to do if you ever want to support Jigsaw? Wait
for it to come to Eclipse?<br>
<br>
I'm personally always in favor of dumbing things down: Ant scripts
are fairly easy to read (they are scripts) and anyone can join in
the fun. I understand that Restlet targets enterprise customers,
but the library itself, even with its ecology of plugins, is
actually quite minimal and light. Somehow over the years the build
process has become very complicated. If you're stuck, I think that
instead of trying to fix this massive structure, it may be worth
rethinking the whole scheme.<br>
<br>
I think it's furthermore worth thinking of an alternative to the
way editions are compiled now, using a preprocessor. This again
makes Restlet a very quirky project, where its source code is not
in fact source code. It's hard to think of a solution that doesn't
present further problems, but this current solution is especially
difficult to work with.<br>
<br>
-Tal<br>
</p>
<br>
<blockquote
cite="mid:CAKtT4xMXrFPSf8TzFpbK3fc+hPsKu3P_KFGRyvEXwVR_T=
type="cite">
<pre wrap="">Hi Jerome, all-
I'm not a big fan of Maven, and so I'd favor a build system that
didn't depend on it. That said, the PDE is a major pain in the ass
for many projects. For many years, we used PDE for all our projects
(which are all built as OSGi bundles), including internal builds of
Restlet, but a while ago we finally got so frustrated with the PDE
that we completely reworked our project and build systems. We
initially tried to use Bndtools, and maybe that would have worked if
we'd stuck with it, but at the time it wasn't well documented. That
might be worth looking into for Restlet.
What we ended up with for our own stuff is a system built around
Gradle ( <a class="moz-txt-link-freetext" href="http://gradle.org/">
http://gradle.org/</a> ). Gradle is similar to Maven in some
ways, but it is super flexible, and you write your build scripts in
groovy/java instead of XML. Gradle is extremely well documented, which
I think is a major argument in its favor over Maven, all technical
differences aside.
There are some pretty big incompatibilities between the way PDE works
and most other build systems, which makes it hard for a single project
to play well with both. In particular, whereas PDE uses OSGi metadata
in the Manifest files to control the build, most other build systems
work by putting that metadata in a build/config file and then
generating the bundle Manifest file during the build process.
Projects that work with both can end up with two different manifest
files, only one of which is used in the final artifact. While the PDE
approach is arguably more consistent with the way OSGi dependencies
work, the PDE environment has never really broken away from its more
narrow focus of building eclipse plugins, is inflexible, and is hard
to extend for more complex projects.
-Dave Fogel
On Fri, Apr 27, 2012 at 3:05 AM, Jerome Louvel
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
We’ve been discussing internally and separately with several contributors
regarding the build issues occurring on the master branch in GitHub,
especially with Eclipse 3.7. I’d like open up the discussion in our
developers list and take this opportunity to clarify our goals for next 2.2
1) Repair the Eclipse PDE build
The current/historical way we use to build from Eclipse is through OSGi
bundles. If you install the PDE plugins (or choose the proper Eclipse
editions), this should work by default as explained here (needs some
update): <a class="moz-txt-link-freetext" href="
http://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html">
http://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html</a>
For version 2.2, we are trying to migrate to the latest Eclipse 3.7 version,
which now includes Maven support by default (built-in m2e plugin). The first
step I’ve been trying to accomplish is to ensure that the pom.xml files
present in the module directories don’t conflict with the usual Eclipse/PDE
build process.
To use Eclipse/PDE build, you either need the “Eclipse Classic” edition
which comes with PDE bundled, or to install PDE on top of the lighter
“Eclipse IDE for Java” edition. Then, if you import both the modules and
the
libraries project as explained in the wiki, you should see the build work
just fine.
We do have remaining issues with OAuth, OpenID extensions, as well as the
examples project that need to be fixed. I’m a bit stuck on this so any help
is welcome. Maybe Kristoffer and/or Martin can help for the OAuth and OpenID
extensions?
2) Make the m2e build work
For 2.2, we would like the master to work with m2e as well (new name for
m2eclipse), as it is now bundled by default since Eclipse 3.7 (IDE for
Java).
Note that currently, our POM.xml files are not manually edited but instead
generated by our forge (ant scripts) from our own module.xml files. This was
necessary in order to support multi-edition builds and distributions in
various channels (Eclipse update site, Maven update site).
So, in addition to adjusting the .project and .classpath files, we should
ensure that we can (re-)generate the proper pom.xml files. Shaun Elliot has
offered to help on that front and other contributions will be welcome, but
we need to be careful when contributing changes to Eclipse project and pom
files.
3) Ensure compatibility when both PDE build and m2e are active
Finally, we should try to make the build with both pde and m2e work at the
same time in case the developers needs to develop in PDE/OSGi mode.
Currently, I see no way to fully turn off m2e for a workspace or a project,
which is annoying. There is probably a solution I’m not aware of.
The minimum is to ensure that there is no conflict and the binaries are
produced in separate directories (bin for PDE and target/classes for m2e).
4) Integrate the org.restlet.ext.osgi extension
Once the previous steps are complete, at least the first ones, we’ll start
integrating the contribution from Bryan Hunt and others currently located
<a class="moz-txt-link-freetext" href="
https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/">
https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/</a>
This will allow fully dynamic usage of Restlet thanks to OSGi, such as
adding new applications or resources on the fly.
Best regards,
Jerome
--
<a class="moz-txt-link-freetext" href="http://www.restlet.com">
http://www.restlet.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/jlouvel">
http://twitter.com/#!/jlouvel</a>
</pre>
</blockquote>
<pre wrap="">
------------------------------------------------------
<a class="moz-txt-link-freetext" href="
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=2956647
">
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=2956647
</a>
</pre>
</blockquote>
</body>
</html>
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2956650
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2956668
Jerome Louvel
2012-05-03 22:02:18 UTC
Permalink
Hi all,



Thanks for the feed-back, that’s really helpful!



Actually, we didn’t really want to change the actual Restlet build system
based on Ant (plus a preprocessor for the multi-edition work). We only
wanted to provide an easier way for developers/contibutors to compile and
test the master Java source code.



As we are clearly moving away from PDE and everyone seems to be fine with
that, the best option seems to get back to our roots and properly
use/explain our Ant build system from IDEs and not just from command line
when preparing Restlet official builds. BTW, Eclipse does provide a nice
support for Ant by default via the Outline view.



In order to remove current ambiguities around Maven, I propose to :

1. Remove the POM files automatically generated from Git repository

a. only generate them for the Maven repository

2. Remove the PDE/MANIFEST files from Git repository

a. the proper MANIFEST are separately generated for the OSGi edition

3. Configure the Eclipse projects’ build path configuration

a. to manage dependencies

4. Re-document the official way to develop with
Eclipse/NetBeans/IntelliJ

a. Git clone

b. import projects (need to add the .project files and similar files to
Git)

c. locate Ant build file

d. edit custom.properties

e. launch Ant targets



How does it sounds?



Best regards,

Jerome

--

<http://www.restlet.com/> http://www.restlet.com

<http://twitter.com/#!/jlouvel> http://twitter.com/#!/jlouvel







De : tpeierls-***@public.gmane.org [mailto:tpeierls-***@public.gmane.org] De la part de Tim
Peierls
Envoyé : mardi 1 mai 2012 22:54
À : code-s0N/mLB9wL+***@public.gmane.org
Objet : Re: Restlet Framework 2.2 - Build issues and Eclipse/OSGi
development



Agree with David and Tal in general. (Full disclosure: I'm an Ant/Ivy user.)



Possible point of divergence is that I don't see how to avoid the
preprocessor-based approach to editions, though I do see the problems with
not having a single body of pure Java source. I wonder how much of the
alternative compilation could be handled with run-time constants and if-else
(trusting to modern JVMs to optimize away the unused branches) and stub
libraries.



--tim

On Tue, May 1, 2012 at 2:44 PM, Tal Liron <tal.liron-KRbUgwfp4vGAiRqxG6I7vAC/***@public.gmane.org>
wrote:

<html style="direction: ltr;">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="UTF-8" text="#000000"
bgcolor="#FFFFFF">
<p>I have to agree with David on much of this.<br>
<br>
1) Maven is a headache. It's important to support Maven
repositories, but it's possible to do so by creating POMs that
simply attach already-built Jars, such that Maven does not become
a requirement for those susceptible to headaches. I think Restlet
has also suffered from this, as small regressions in POMs
continuously frustrate would-be contributors. Maven is finicky.
Also, as David points out, there are other tools that support
Maven repositories. Gradle, or even use Ivy directly (the tool on
which Gradle is based) from Ant tasks. Point being: you don't need
Maven for Maven.<br>
<br>
2) If Maven is a headache, PDE is a disaster. Since Restlet does
not depend on Eclipse/Equinox, this dependency always struck me as
odd. It's quite possible to build OSGi without any of that; and,
again, like Maven, not everybody needs or wants or likes OSGi.
What are you going to do if you ever want to support Jigsaw? Wait
for it to come to Eclipse?<br>
<br>
I'm personally always in favor of dumbing things down: Ant scripts
are fairly easy to read (they are scripts) and anyone can join in
the fun. I understand that Restlet targets enterprise customers,
but the library itself, even with its ecology of plugins, is
actually quite minimal and light. Somehow over the years the build
process has become very complicated. If you're stuck, I think that
instead of trying to fix this massive structure, it may be worth
rethinking the whole scheme.<br>
<br>
I think it's furthermore worth thinking of an alternative to the
way editions are compiled now, using a preprocessor. This again
makes Restlet a very quirky project, where its source code is not
in fact source code. It's hard to think of a solution that doesn't
present further problems, but this current solution is especially
difficult to work with.<br>
<br>
-Tal<br>
</p>
<br>
On 05/01/2012 01:27 PM, David Fogel wrote:
<blockquote
cite="mid:CAKtT4xMXrFPSf8TzFpbK3fc+hPsKu3P_KFGRyvEXwVR_T=5cGg-***@public.gmane.orgl.com
"
type="cite">
<pre wrap="">Hi Jerome, all-


I'm not a big fan of Maven, and so I'd favor a build system that
didn't depend on it. That said, the PDE is a major pain in the ass
for many projects. For many years, we used PDE for all our projects
(which are all built as OSGi bundles), including internal builds of
Restlet, but a while ago we finally got so frustrated with the PDE
that we completely reworked our project and build systems. We
initially tried to use Bndtools, and maybe that would have worked if
we'd stuck with it, but at the time it wasn't well documented. That
might be worth looking into for Restlet.

What we ended up with for our own stuff is a system built around

Gradle ( <a class="moz-txt-link-freetext"
href="http://gradle.org/">http://gradle.org/</a> ). Gradle is similar to
Maven in some

ways, but it is super flexible, and you write your build scripts in
groovy/java instead of XML. Gradle is extremely well documented, which
I think is a major argument in its favor over Maven, all technical
differences aside.

There are some pretty big incompatibilities between the way PDE works
and most other build systems, which makes it hard for a single project
to play well with both. In particular, whereas PDE uses OSGi metadata
in the Manifest files to control the build, most other build systems
work by putting that metadata in a build/config file and then
generating the bundle Manifest file during the build process.
Projects that work with both can end up with two different manifest
files, only one of which is used in the final artifact. While the PDE
approach is arguably more consistent with the way OSGi dependencies
work, the PDE environment has never really broken away from its more
narrow focus of building eclipse plugins, is inflexible, and is hard
to extend for more complex projects.

-Dave Fogel

On Fri, Apr 27, 2012 at 3:05 AM, Jerome Louvel

<a class="moz-txt-link-rfc2396E"
href="mailto:jerome.louvel-s0N/***@public.gmane.org">&lt;jerome.louvel-s0N/***@public.gmane.org <mailto:lt%3Bjerome.louvel-s0N/***@public.gmane.org> &gt;</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,




We’ve been discussing internally and separately with several contributors
regarding the build issues occurring on the master branch in GitHub,
especially with Eclipse 3.7. I’d like open up the discussion in our
developers list and take this opportunity to clarify our goals for next 2.2
version and better coordinate our efforts and expectations :



1) Repair the Eclipse PDE build



The current/historical way we use to build from Eclipse is through OSGi
bundles. If you install the PDE plugins (or choose the proper Eclipse
editions), this should work by default as explained here (needs some

update): <a class="moz-txt-link-freetext"
href="http://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html">ht
tp://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html</a>




For version 2.2, we are trying to migrate to the latest Eclipse 3.7 version,
which now includes Maven support by default (built-in m2e plugin). The first
step I’ve been trying to accomplish is to ensure that the pom.xml files
present in the module directories don’t conflict with the usual Eclipse/PDE
build process.



To use Eclipse/PDE build, you either need the “Eclipse Classic” edition
which comes with PDE bundled, or to install PDE on top of the lighter
“Eclipse IDE for Java” edition. Then, if you import both the modules and the
libraries project as explained in the wiki, you should see the build work
just fine.



We do have remaining issues with OAuth, OpenID extensions, as well as the
examples project that need to be fixed. I’m a bit stuck on this so any help
is welcome. Maybe Kristoffer and/or Martin can help for the OAuth and OpenID
extensions?



2) Make the m2e build work



For 2.2, we would like the master to work with m2e as well (new name for
m2eclipse), as it is now bundled by default since Eclipse 3.7 (IDE for
Java).



Note that currently, our POM.xml files are not manually edited but instead
generated by our forge (ant scripts) from our own module.xml files. This was
necessary in order to support multi-edition builds and distributions in
various channels (Eclipse update site, Maven update site).



So, in addition to adjusting the .project and .classpath files, we should
ensure that we can (re-)generate the proper pom.xml files. Shaun Elliot has
offered to help on that front and other contributions will be welcome, but
we need to be careful when contributing changes to Eclipse project and pom
files.



3) Ensure compatibility when both PDE build and m2e are active



Finally, we should try to make the build with both pde and m2e work at the
same time in case the developers needs to develop in PDE/OSGi mode.
Currently, I see no way to fully turn off m2e for a workspace or a project,
which is annoying. There is probably a solution I’m not aware of.



The minimum is to ensure that there is no conflict and the binaries are
produced in separate directories (bin for PDE and target/classes for m2e).



4) Integrate the org.restlet.ext.osgi extension



Once the previous steps are complete, at least the first ones, we’ll start
integrating the contribution from Bryan Hunt and others currently located
at:

<a class="moz-txt-link-freetext"
href="https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/"
Post by Tal Liron
https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/</a>
This will allow fully dynamic usage of Restlet thanks to OSGi, such as
adding new applications or resources on the fly.



Best regards,

Jerome

--

<a class="moz-txt-link-freetext"
href="http://www.restlet.com">http://www.restlet.com</a>

<a class="moz-txt-link-freetext"
href="http://twitter.com/#!/jlouvel">http://twitter.com/#!/jlouvel</a>


</pre>
</blockquote>
<pre wrap="">
------------------------------------------------------
<a class="moz-txt-link-freetext"
href="http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458
<http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=
2956647>
&amp;dsMessageId=2956647">http://restlet.tigris.org/ds/viewMessage.do?dsForu
mId=7458
<http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=
2956647> &amp;dsMessageId=2956647</a>
</pre>
</blockquote>
</body>
</html>

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458
<http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2956
650> &dsMessageId=2956650

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2957452
Tal Liron
2012-05-03 22:13:11 UTC
Permalink
<html style="direction: ltr;">
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="latin-charset" text="#000000"
bgcolor="#FFFFFF">
<p>This sounds like a very refreshing move to me.<br>
<br>
But, I think it's also worth providing a guide to how to work with
the source pre-processor. As it stands, you can't just edit a
.java file and have Eclipse do the rest: you have to run the
pre-processor first. A lot of IDE functionality gets lost: debug
breakpoints, hotswapping, etc. Of course, source-level syntax
checking and formatting also does not work. This makes Restlet
quirky, odd, and in my personal view frustrating to work with at
the source level. And I tend to have a lot of patience for
quirkiness... If your goal is an easier way for contributors to
work with the source code, this remains an issue.<br>
<br>
I've been working a lot on Eclipse plugins lately ("real"
extensions of Eclipse, not merely using the PDE to generate OSGi
bundles), and wonder if we can write an Eclipse Builder that
incorporates the preprocessor, so that Eclipse will know what to
do with these .java files. This, of course, won't integrate with
NetBeans/IntelliJ, but I don't think it's wrong for Restlet to
insist on a specific IDE for best experience. (It pretty much
already does.)<br>
<br>
I'm very swamped with time lately (get prepared for an exciting
announcement soon), but maybe in the future I can contribute
something like that, better yet a more generic Eclipse plugin to
deal with source pre-processors. Or maybe something like this
already exists and I'm not aware of it.<br>
<br>
-Tal<br>
</p>
<br>
On 05/03/2012 05:02 PM, Jerome Louvel wrote:
<blockquote cite="mid:000e01cd2978$68e84800$3ab8d800$@restlet.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1047995077;
mso-list-type:hybrid;
mso-list-template-ids:312235962 67895297 67895299 67895301 67895297 67895299 67895301 67895297 67895299 67895301;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1818842723;
mso-list-type:hybrid;
mso-list-template-ids:-1433487794 67895311 67895321 67895323 67895311 67895321 67895323 67895311 67895321 67895323;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">Hi all,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">Thanks for the feed-back, that&#8217;s really
helpful!<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">Actually, we didn&#8217;t really want to change the
actual Restlet build system based on Ant (plus a
preprocessor for the multi-edition work). We only wanted to
provide an easier way for developers/contibutors to compile
and test the master Java source code.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">As we are clearly moving away from PDE and
everyone seems to be fine with that, the best option seems
to get back to our roots and properly use/explain our Ant
build system from IDEs and not just from command line when
preparing Restlet official builds. BTW, Eclipse does provide
a nice support for Ant by default via the Outline view.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">In order to remove current ambiguities around
Maven, I propose to :<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l1 level1 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">1.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">Remove the POM files automatically generated
from Git repository<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level2 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">a.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">only generate them for the Maven repository<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l1 level1 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">2.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">Remove the PDE/MANIFEST files from Git
repository<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level2 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">a.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">the proper MANIFEST are separately generated
for the OSGi edition<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l1 level1 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">3.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">Configure the Eclipse projects&#8217; build path
configuration<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level2 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">a.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">to manage dependencies<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l1 level1 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">4.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">Re-document the official way to develop with
Eclipse/NetBeans/IntelliJ<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level2 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">a.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">Git clone<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level2 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">b.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">import projects (need to add the .project files
and similar files to Git)<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level2 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">c.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">locate Ant build file<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level2 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">d.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">edit custom.properties<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level2 lfo2"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><span style="mso-list:Ignore">e.<span
style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">launch Ant targets<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US">How does it sounds?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US">Jerome<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US">--<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D;mso-fareast-language:EN-US"><a
moz-do-not-send="true" href="http://www.restlet.com/"><span
style="color:#1F497D" lang="EN-US">http://www.restlet.com</span></a></span><span
style="font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D;mso-fareast-language:EN-US"><a
moz-do-not-send="true"
href="http://twitter.com/#%21/jlouvel"><span
style="color:#1F497D">http://twitter.com/#!/jlouvel</span></a><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"
lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">De&nbsp;:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
<a class="moz-txt-link-abbreviated" href="mailto:tpeierls-***@public.gmane.org">tpeierls-***@public.gmane.org</a> [<a class="moz-txt-link-freetext" href="mailto:tpeierls-***@public.gmane.org">mailto:tpeierls-***@public.gmane.org</a>] <b>De la
part de</b> Tim Peierls<br>
<b>Envoy&eacute;&nbsp;:</b> mardi 1 mai 2012 22:54<br>
<b>&Agrave;&nbsp;:</b> <a class="moz-txt-link-abbreviated" href="mailto:code-s0N/mLB9wL+***@public.gmane.org">code-s0N/mLB9wL+***@public.gmane.org</a><br>
<b>Objet&nbsp;:</b> Re: Restlet Framework 2.2 - Build issues and
Eclipse/OSGi development<o:p></o:p></span></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Agree with David and Tal in general. (Full
disclosure: I'm an Ant/Ivy user.)<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">Possible point of divergence is that I
don't see how to avoid the preprocessor-based approach to
editions, though I do see the problems with not having a
single body of pure Java source. I wonder how much of the
alternative compilation could be handled with run-time
constants and if-else (trusting to modern JVMs to optimize
away the unused branches) and stub libraries.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">--tim<o:p></o:p></p>
<div>
<p class="MsoNormal">On Tue, May 1, 2012 at 2:44 PM, Tal
Liron &lt;<a moz-do-not-send="true"
href="mailto:tal.liron-KRbUgwfp4vGAiRqxG6I7vAC/***@public.gmane.org"
target="_blank">tal.liron-KRbUgwfp4vGAiRqxG6I7vAC/***@public.gmane.org</a>&gt;
wrote:<o:p></o:p></p> <p class="MsoNormal">&lt;html style="direction: ltr;"&gt;<br>
&nbsp;&lt;head&gt;<br>
&nbsp; &nbsp;&lt;meta content="text/html; charset=UTF-8"
http-equiv="Content-Type"&gt;<br>
&nbsp; &nbsp;&lt;style&gt;body p { margin-bottom: 0cm; margin-top:
0pt; } &lt;/style&gt;<br>
&nbsp;&lt;/head&gt;<br>
&nbsp;&lt;body style="direction: ltr;"<br>
&nbsp; &nbsp;bidimailui-detected-decoding-type="UTF-8"
text="#000000"<br>
&nbsp; &nbsp;bgcolor="#FFFFFF"&gt;<br>
&nbsp; &nbsp;&lt;p&gt;I have to agree with David on much of
this.&lt;br&gt;<br>
&nbsp; &nbsp; &nbsp;&lt;br&gt;<br>
&nbsp; &nbsp; &nbsp;1) Maven is a headache. It's important to support
Maven<br>
&nbsp; &nbsp; &nbsp;repositories, but it's possible to do so by creating
POMs that<br>
&nbsp; &nbsp; &nbsp;simply attach already-built Jars, such that Maven
does not become<br>
&nbsp; &nbsp; &nbsp;a requirement for those susceptible to headaches. I
think Restlet<br>
&nbsp; &nbsp; &nbsp;has also suffered from this, as small regressions in
POMs<br>
&nbsp; &nbsp; &nbsp;continuously frustrate would-be contributors. Maven
is finicky.<br>
&nbsp; &nbsp; &nbsp;Also, as David points out, there are other tools that
support<br>
&nbsp; &nbsp; &nbsp;Maven repositories. Gradle, or even use Ivy directly
(the tool on<br>
&nbsp; &nbsp; &nbsp;which Gradle is based) from Ant tasks. Point being:
you don't need<br>
&nbsp; &nbsp; &nbsp;Maven for Maven.&lt;br&gt;<br>
&nbsp; &nbsp; &nbsp;&lt;br&gt;<br>
&nbsp; &nbsp; &nbsp;2) If Maven is a headache, PDE is a disaster. Since
Restlet does<br>
&nbsp; &nbsp; &nbsp;not depend on Eclipse/Equinox, this dependency always
struck me as<br>
&nbsp; &nbsp; &nbsp;odd. It's quite possible to build OSGi without any of
that; and,<br>
&nbsp; &nbsp; &nbsp;again, like Maven, not everybody needs or wants or
likes OSGi.<br>
&nbsp; &nbsp; &nbsp;What are you going to do if you ever want to support
Jigsaw? Wait<br>
&nbsp; &nbsp; &nbsp;for it to come to Eclipse?&lt;br&gt;<br>
&nbsp; &nbsp; &nbsp;&lt;br&gt;<br>
&nbsp; &nbsp; &nbsp;I'm personally always in favor of dumbing things
down: Ant scripts<br>
&nbsp; &nbsp; &nbsp;are fairly easy to read (they are scripts) and anyone
can join in<br>
&nbsp; &nbsp; &nbsp;the fun. I understand that Restlet targets enterprise
customers,<br>
&nbsp; &nbsp; &nbsp;but the library itself, even with its ecology of
plugins, is<br>
&nbsp; &nbsp; &nbsp;actually quite minimal and light. Somehow over the
years the build<br>
&nbsp; &nbsp; &nbsp;process has become very complicated. If you're stuck,
I think that<br>
&nbsp; &nbsp; &nbsp;instead of trying to fix this massive structure, it
may be worth<br>
&nbsp; &nbsp; &nbsp;rethinking the whole scheme.&lt;br&gt;<br>
&nbsp; &nbsp; &nbsp;&lt;br&gt;<br>
&nbsp; &nbsp; &nbsp;I think it's furthermore worth thinking of an
alternative to the<br>
&nbsp; &nbsp; &nbsp;way editions are compiled now, using a preprocessor.
This again<br>
&nbsp; &nbsp; &nbsp;makes Restlet a very quirky project, where its source
code is not<br>
&nbsp; &nbsp; &nbsp;in fact source code. It's hard to think of a solution
that doesn't<br>
&nbsp; &nbsp; &nbsp;present further problems, but this current solution
is especially<br>
&nbsp; &nbsp; &nbsp;difficult to work with.&lt;br&gt;<br>
&nbsp; &nbsp; &nbsp;&lt;br&gt;<br>
&nbsp; &nbsp; &nbsp;-Tal&lt;br&gt;<br>
&nbsp; &nbsp;&lt;/p&gt;<br>
&nbsp; &nbsp;&lt;br&gt;<br>
&nbsp; &nbsp;On 05/01/2012 01:27 PM, David Fogel wrote:<br>
&nbsp; &nbsp;&lt;blockquote<br>
cite="mid:CAKtT4xMXrFPSf8TzFpbK3fc+hPsKu3P_KFGRyvEXwVR_T=<a
moz-do-not-send="true" href="mailto:5cGg-JsoAwUIsXosN+***@public.gmane.org">5cGg-JsoAwUIsXosN+***@public.gmane.org</a>"<br>
&nbsp; &nbsp; &nbsp;type="cite"&gt;<br>
&nbsp; &nbsp; &nbsp;&lt;pre wrap=""&gt;Hi Jerome, all-<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
I'm not a big fan of Maven, and so I'd favor a build
system that<br>
didn't depend on it. &nbsp;That said, the PDE is a major pain
in the ass<br>
for many projects. For many years, we used PDE for all
our projects<br>
(which are all built as OSGi bundles), including
internal builds of<br>
Restlet, but a while ago we finally got so frustrated
with the PDE<br>
that we completely reworked our project and build
systems. &nbsp;We<br>
initially tried to use Bndtools, and maybe that would
have worked if<br>
we'd stuck with it, but at the time it wasn't well
documented. &nbsp;That<br>
might be worth looking into for Restlet.<br>
<br>
What we ended up with for our own stuff is a system
built around<o:p></o:p></p>
</div>
<p class="MsoNormal">Gradle ( &lt;a
class="moz-txt-link-freetext" href="<a
moz-do-not-send="true" href="http://gradle.org/"
target="_blank">http://gradle.org/</a>"&gt;<a
moz-do-not-send="true" href="http://gradle.org/"
target="_blank">http://gradle.org/</a>&lt;/a&gt; ).
&nbsp;Gradle is similar to Maven in some<o:p></o:p></p>
<div>
<p class="MsoNormal">ways, but it is super flexible, and
you write your build scripts in<br>
groovy/java instead of XML. Gradle is extremely well
documented, which<br>
I think is a major argument in its favor over Maven, all
technical<br>
differences aside.<br>
<br>
There are some pretty big incompatibilities between the
way PDE works<br>
and most other build systems, which makes it hard for a
single project<br>
to play well with both. &nbsp;In particular, whereas PDE uses
OSGi metadata<br>
in the Manifest files to control the build, most other
build systems<br>
work by putting that metadata in a build/config file and
then<br>
generating the bundle Manifest file during the build
process.<br>
Projects that work with both can end up with two
different manifest<br>
files, only one of which is used in the final artifact.
While the PDE<br>
approach is arguably more consistent with the way OSGi
dependencies<br>
work, the PDE environment has never really broken away
from its more<br>
narrow focus of building eclipse plugins, is inflexible,
and is hard<br>
to extend for more complex projects.<br>
<br>
-Dave Fogel<br>
<br>
On Fri, Apr 27, 2012 at 3:05 AM, Jerome Louvel<o:p></o:p></p>
</div>
<p class="MsoNormal">&lt;a class="moz-txt-link-rfc2396E"
href="mailto:<a moz-do-not-send="true"
href="mailto:jerome.louvel-s0N/***@public.gmane.org">jerome.louvel-s0N/***@public.gmane.org</a>"&gt;&amp;<a
moz-do-not-send="true"
href="mailto:lt%3Bjerome.louvel-s0N/***@public.gmane.org">lt;jerome.louvel-s0N/***@public.gmane.org</a>&amp;gt;&lt;/a&gt;
wrote:<br>
&lt;/pre&gt;<br>
&nbsp; &nbsp; &nbsp;&lt;blockquote type="cite"&gt;<br>
&nbsp; &nbsp; &nbsp; &nbsp;&lt;pre wrap=""&gt;Hi all,<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<br>
We&#8217;ve been discussing internally and separately with
several contributors<br>
regarding the build issues occurring on the master
branch in GitHub,<br>
especially with Eclipse 3.7. I&#8217;d like open up the
discussion in our<br>
developers list and take this opportunity to clarify our
goals for next 2.2<br>
version and better coordinate our efforts and
expectations :<br>
<br>
<br>
<br>
1) Repair the Eclipse PDE build<br>
<br>
<br>
<br>
The current/historical way we use to build from Eclipse
is through OSGi<br>
bundles. If you install the PDE plugins (or choose the
proper Eclipse<br>
editions), this should work by default as explained here
(needs some<o:p></o:p></p>
</div>
<p class="MsoNormal">update): &lt;a
class="moz-txt-link-freetext" href="<a
moz-do-not-send="true"
href="http://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html"
target="_blank">http://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html</a>"&gt;<a
moz-do-not-send="true"
href="http://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html"
target="_blank">http://wiki.restlet.org/developers/295-restlet/g1/216-restlet.html</a>&lt;/a&gt;<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
For version 2.2, we are trying to migrate to the
latest Eclipse 3.7 version,<br>
which now includes Maven support by default (built-in
m2e plugin). The first<br>
step I&#8217;ve been trying to accomplish is to ensure that
the pom.xml files<br>
present in the module directories don&#8217;t conflict with
the usual Eclipse/PDE<br>
build process.<br>
<br>
<br>
<br>
To use Eclipse/PDE build, you either need the &#8220;Eclipse
Classic&#8221; edition<br>
which comes with PDE bundled, or to install PDE on top
of the lighter<br>
&#8220;Eclipse IDE for Java&#8221; edition. Then, if you import
both the modules and the<br>
libraries project as explained in the wiki, you should
see the build work<br>
just fine.<br>
<br>
<br>
<br>
We do have remaining issues with OAuth, OpenID
extensions, as well as the<br>
examples project that need to be fixed. I&#8217;m a bit
stuck on this so any help<br>
is welcome. Maybe Kristoffer and/or Martin can help
for the OAuth and OpenID<br>
extensions?<br>
<br>
<br>
<br>
2) Make the m2e build work<br>
<br>
<br>
<br>
For 2.2, we would like the master to work with m2e as
well (new name for<br>
m2eclipse), as it is now bundled by default since
Eclipse 3.7 (IDE for<br>
Java).<br>
<br>
<br>
<br>
Note that currently, our POM.xml files are not
manually edited but instead<br>
generated by our forge (ant scripts) from our own
module.xml files. This was<br>
necessary in order to support multi-edition builds and
distributions in<br>
various channels (Eclipse update site, Maven update
site).<br>
<br>
<br>
<br>
So, in addition to adjusting the .project and
.classpath files, we should<br>
ensure that we can (re-)generate the proper pom.xml
files. Shaun Elliot has<br>
offered to help on that front and other contributions
will be welcome, but<br>
we need to be careful when contributing changes to
Eclipse project and pom<br>
files.<br>
<br>
<br>
<br>
3) Ensure compatibility when both PDE build and m2e
are active<br>
<br>
<br>
<br>
Finally, we should try to make the build with both pde
and m2e work at the<br>
same time in case the developers needs to develop in
PDE/OSGi mode.<br>
Currently, I see no way to fully turn off m2e for a
workspace or a project,<br>
which is annoying. There is probably a solution I&#8217;m
not aware of.<br>
<br>
<br>
<br>
The minimum is to ensure that there is no conflict and
the binaries are<br>
produced in separate directories (bin for PDE and
target/classes for m2e).<br>
<br>
<br>
<br>
4) Integrate the org.restlet.ext.osgi extension<br>
<br>
<br>
<br>
Once the previous steps are complete, at least the
first ones, we&#8217;ll start<br>
integrating the contribution from Bryan Hunt and
others currently located<br>
at:<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">&lt;a class="moz-txt-link-freetext"
href="<a moz-do-not-send="true"
href="https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/"
target="_blank">https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/</a>"&gt;<a
moz-do-not-send="true"
href="https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/"
target="_blank">https://github.com/BryanHunt/Restlet-Extension-for-OSGi-Environments/</a>&lt;/a&gt;<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
This will allow fully dynamic usage of Restlet thanks to
OSGi, such as<br>
adding new applications or resources on the fly.<br>
<br>
<br>
<br>
Best regards,<br>
<br>
Jerome<br>
<br>
--<o:p></o:p></p>
</div>
<p class="MsoNormal">&lt;a class="moz-txt-link-freetext"
href="<a moz-do-not-send="true"
href="http://www.restlet.com" target="_blank">http://www.restlet.com</a>"&gt;<a
moz-do-not-send="true" href="http://www.restlet.com"
target="_blank">http://www.restlet.com</a>&lt;/a&gt;<br>
<br>
&lt;a class="moz-txt-link-freetext" href="<a
moz-do-not-send="true"
href="http://twitter.com/#%21/jlouvel" target="_blank">http://twitter.com/#!/jlouvel</a>"&gt;<a
moz-do-not-send="true"
href="http://twitter.com/#%21/jlouvel" target="_blank">http://twitter.com/#!/jlouvel</a>&lt;/a&gt;<br>
<br>
<br>
&lt;/pre&gt;<br>
&nbsp; &nbsp; &nbsp;&lt;/blockquote&gt;<br>
&nbsp; &nbsp; &nbsp;&lt;pre wrap=""&gt;<br>
------------------------------------------------------<br>
&lt;a class="moz-txt-link-freetext" href="<a
moz-do-not-send="true"
href="http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;amp;dsMessageId=2956647"
target="_blank">http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;amp;dsMessageId=2956647</a>"&gt;<a
moz-do-not-send="true"
href="http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;amp;dsMessageId=2956647"
target="_blank">http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;amp;dsMessageId=2956647</a>&lt;/a&gt;<br>
&lt;/pre&gt;<br>
&nbsp; &nbsp;&lt;/blockquote&gt;<br>
&nbsp;&lt;/body&gt;<br>
&lt;/html&gt;<br>
<br>
------------------------------------------------------<br>
<a moz-do-not-send="true"
href="http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=2956650"
target="_blank">http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=2956650</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</blockquote>
</body>
</html>

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2957457
Jerome Louvel
2012-05-13 13:56:27 UTC
Permalink
Hi Tal and all,



I've been able to complete the first tasks in Git master branch:

· The Eclipse projects don’t rely on PDE/OSGi anymore but on regular
Eclipse projects dependencies

· Manifest and pom.xml files have been removed

· Only Java nature has been kept on the Eclipse project files

· The code now uses Java 1.6 and compiles fine in Eclipse

· Retrotranslator support (for Java 1.4) has been removed altogether


· All unit tests pass fine in Eclipse (tested on Win 7)



We still need to fix some issues with the Ant build script that prevent the
whole thing to run through properly. Also, documentation needs to be updated
and completed. I have started this task in GitHub wiki, migrating/adapting
existing content from the Daisy wiki:
https://github.com/restlet/restlet-framework-java/wiki/Building-the-source



@Tal : it is already possible to directly use Eclipse to edit the Java files
and run them, without using the pre-processor! Our pre-processor annotations
have been designed as Java comments that can be ignored by default. In this
case you somewhat fall back into the JavaSE edition. This is the way we
develop most of the time. You can even pass the whole test suite in this
mode. Of course, when dealing with a specific edition issue, you need to
look at the code pre-processed for it in the “build/temp” folder.



Regarding your idea to integrate the pre-processor with Eclipse Java
builder, this a good idea… actually we already considered something along
these lines for Restlet/Eclipse tooling:
http://wiki.restlet.org/developers/172-restlet/g3/361-restlet.html



The first step would be to have an Eclipse View to see how the code of the
current Java editor looks like after pre-processing for a selected edition.
Otherwise, considering that each edition can add/remove files and do other
advanced things, it is really necessary at some point to look at the code
produced for each edition in the dedicated build folder (in build/temp).



Best regards,

Jerome

--

<http://www.restlet.com/> http://www.restlet.com

<http://twitter.com/#!/jlouvel> http://twitter.com/#!/jlouvel







-----Message d'origine-----
De : Tal Liron [mailto:tal.liron-KRbUgwfp4vGAiRqxG6I7vAC/***@public.gmane.org]
Envoyé : vendredi 4 mai 2012 00:13
À : code-s0N/mLB9wL+***@public.gmane.org
Objet : Re: Restlet Framework 2.2 - Build issues and Eclipse/OSGi
development



This sounds like a very refreshing move to me.<br>



But, I think it's also worth providing a guide to how to work with

the source pre-processor. As it stands, you can't just edit a

.java file and have Eclipse do the rest: you have to run the

pre-processor first. A lot of IDE functionality gets lost: debug

breakpoints, hotswapping, etc. Of course, source-level syntax

checking and formatting also does not work. This makes Restlet

quirky, odd, and in my personal view frustrating to work with at

the source level. And I tend to have a lot of patience for

quirkiness... If your goal is an easier way for contributors to

work with the source code, this remains an issue.<br>

<br>

I've been working a lot on Eclipse plugins lately ("real"

extensions of Eclipse, not merely using the PDE to generate OSGi

bundles), and wonder if we can write an Eclipse Builder that

incorporates the preprocessor, so that Eclipse will know what to

do with these .java files. This, of course, won't integrate with

NetBeans/IntelliJ, but I don't think it's wrong for Restlet to

insist on a specific IDE for best experience. (It pretty much

already does.)<br>

<br>

I'm very swamped with time lately (get prepared for an exciting

announcement soon), but maybe in the future I can contribute

something like that, better yet a more generic Eclipse plugin to

deal with source pre-processors. Or maybe something like this

already exists and I'm not aware of it.<br>



-Tal

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2960149
Martin Svensson
2012-05-02 06:05:42 UTC
Permalink
Just to be clear, what is the exact problem with the OAuth/OpenId extensions (and how do I test those). When importing those modules and doing a "convert to maven..." project everything works fine. Does the problem happen when you do a "import existing java project?"

thanks,

martin

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2956746
Jerome Louvel
2012-05-03 22:06:01 UTC
Permalink
Hi Martin,

When I import the Restlet modules in Eclipse 3.7.2, I get those warning
messages below, and can't get rid of them. Note that I didn't do any
"Convert to Maven" action.

I guess if we remove the pom.xml files with Git (see other message), then
we'll solve this problem as well.

Best regards,
Jerome
--
http://www.restlet.com
http://twitter.com/#!/jlouvel



Description Resource Path Location Type
ArtifactDescriptorException: Failed to read artifact descriptor for
org.restlet.dev:org.restlet:jar:2.2-SNAPSHOT: ArtifactResolutionException:
Failure to transfer org.restlet.dev:org.restlet:pom:2.2-SNAPSHOT from
http://download.java.net/maven/1 was cached in the local repository,
resolution will not be reattempted until the update interval of maven1-java
has elapsed or updates are forced. Original error: Could not transfer
artifact org.restlet.dev:org.restlet:pom:2.2-SNAPSHOT from/to maven1-java
(http://download.java.net/maven/1): No connector available to access
repository maven1-java (http://download.java.net/maven/1) of type legacy
using the available factories AsyncRepositoryConnectorFactory,
WagonRepositoryConnectorFactory pom.xml /org.restlet.ext.oauth line 1
Maven Dependency Problem
ArtifactDescriptorException: Failed to read artifact descriptor for
org.restlet.dev:org.restlet:jar:2.2-SNAPSHOT: ArtifactResolutionException:
Failure to transfer org.restlet.dev:org.restlet:pom:2.2-SNAPSHOT from
http://download.java.net/maven/1 was cached in the local repository,
resolution will not be reattempted until the update interval of maven1-java
has elapsed or updates are forced. Original error: Could not transfer
artifact org.restlet.dev:org.restlet:pom:2.2-SNAPSHOT from/to maven1-java
(http://download.java.net/maven/1): No connector available to access
repository maven1-java (http://download.java.net/maven/1) of type legacy
using the available factories AsyncRepositoryConnectorFactory,
WagonRepositoryConnectorFactory pom.xml /org.restlet.ext.openid line 1
Maven Dependency Problem
ArtifactDescriptorException: Failed to read artifact descriptor for
org.restlet.dev:org.restlet.ext.freemarker:jar:2.2-SNAPSHOT:
ArtifactResolutionException: Failure to transfer
org.restlet.dev:org.restlet.ext.freemarker:pom:2.2-SNAPSHOT from
http://download.java.net/maven/1 was cached in the local repository,
resolution will not be reattempted until the update interval of maven1-java
has elapsed or updates are forced. Original error: Could not transfer
artifact org.restlet.dev:org.restlet.ext.freemarker:pom:2.2-SNAPSHOT from/to
maven1-java (http://download.java.net/maven/1): No connector available to
access repository maven1-java (http://download.java.net/maven/1) of type
legacy using the available factories AsyncRepositoryConnectorFactory,
WagonRepositoryConnectorFactory pom.xml /org.restlet.ext.oauth line 1
Maven Dependency Problem
ArtifactDescriptorException: Failed to read artifact descriptor for
org.restlet.dev:org.restlet.ext.json:jar:2.2-SNAPSHOT:
ArtifactResolutionException: Failure to transfer
org.restlet.dev:org.restlet.ext.json:pom:2.2-SNAPSHOT from
http://download.java.net/maven/1 was cached in the local repository,
resolution will not be reattempted until the update interval of maven1-java
has elapsed or updates are forced. Original error: Could not transfer
artifact org.restlet.dev:org.restlet.ext.json:pom:2.2-SNAPSHOT from/to
maven1-java (http://download.java.net/maven/1): No connector available to
access repository maven1-java (http://download.java.net/maven/1) of type
legacy using the available factories AsyncRepositoryConnectorFactory,
WagonRepositoryConnectorFactory pom.xml /org.restlet.ext.oauth line 1
Maven Dependency Problem
ArtifactDescriptorException: Failed to read artifact descriptor for
org.restlet.dev:org.restlet.ext.json:jar:2.2-SNAPSHOT:
ArtifactResolutionException: Failure to transfer
org.restlet.dev:org.restlet.ext.json:pom:2.2-SNAPSHOT from
http://download.java.net/maven/1 was cached in the local repository,
resolution will not be reattempted until the update interval of maven1-java
has elapsed or updates are forced. Original error: Could not transfer
artifact org.restlet.dev:org.restlet.ext.json:pom:2.2-SNAPSHOT from/to
maven1-java (http://download.java.net/maven/1): No connector available to
access repository maven1-java (http://download.java.net/maven/1) of type
legacy using the available factories AsyncRepositoryConnectorFactory,
WagonRepositoryConnectorFactory pom.xml /org.restlet.ext.openid line 1
Maven Dependency Problem
ArtifactDescriptorException: Failed to read artifact descriptor for
org.restlet.dev:org.restlet.ext.wadl:jar:2.2-SNAPSHOT:
ArtifactResolutionException: Failure to transfer
org.restlet.dev:org.restlet.ext.wadl:pom:2.2-SNAPSHOT from
http://download.java.net/maven/1 was cached in the local repository,
resolution will not be reattempted until the update interval of maven1-java
has elapsed or updates are forced. Original error: Could not transfer
artifact org.restlet.dev:org.restlet.ext.wadl:pom:2.2-SNAPSHOT from/to
maven1-java (http://download.java.net/maven/1): No connector available to
access repository maven1-java (http://download.java.net/maven/1) of type
legacy using the available factories AsyncRepositoryConnectorFactory,
WagonRepositoryConnectorFactory pom.xml /org.restlet.ext.oauth line 1
Maven Dependency Problem
ArtifactDescriptorException: Failed to read artifact descriptor for
org.restlet.dev:org.restlet.ext.xml:jar:2.2-SNAPSHOT:
ArtifactResolutionException: Failure to transfer
org.restlet.dev:org.restlet.ext.xml:pom:2.2-SNAPSHOT from
http://download.java.net/maven/1 was cached in the local repository,
resolution will not be reattempted until the update interval of maven1-java
has elapsed or updates are forced. Original error: Could not transfer
artifact org.restlet.dev:org.restlet.ext.xml:pom:2.2-SNAPSHOT from/to
maven1-java (http://download.java.net/maven/1): No connector available to
access repository maven1-java (http://download.java.net/maven/1) of type
legacy using the available factories AsyncRepositoryConnectorFactory,
WagonRepositoryConnectorFactory pom.xml /org.restlet.ext.openid line 1
Maven Dependency Problem
Missing artifact com.google.code.guice:guice:jar:2.0 pom.xml
/org.restlet.ext.openid line 1 Maven Dependency Problem
Missing artifact commons-codec:commons-codec:jar:1.4 pom.xml
/org.restlet.ext.openid line 1 Maven Dependency Problem
Missing artifact commons-codec:commons-codec:jar:1.5 pom.xml
/org.restlet.ext.oauth line 1 Maven Dependency Problem
Missing artifact commons-dbcp:commons-dbcp:jar:1.3 pom.xml
/org.restlet.ext.oauth line 1 Maven Dependency Problem
Missing artifact commons-logging:commons-logging:jar:1.1.1 pom.xml
/org.restlet.ext.openid line 1 Maven Dependency Problem
Missing artifact commons-pool:commons-pool:jar:1.5.6 pom.xml
/org.restlet.ext.oauth line 1 Maven Dependency Problem
Missing artifact net.jcip:jcip-annotations:jar:1.0 pom.xml
/org.restlet.ext.openid line 1 Maven Dependency Problem
Missing artifact net.oauth.core:oauth:jar:20090617 pom.xml
/org.restlet.ext.oauth line 1 Maven Dependency Problem
Missing artifact net.sourceforge.nekohtml:nekohtml:jar:1.9.14 pom.xml
/org.restlet.ext.openid line 1 Maven Dependency Problem
Missing artifact org.apache.httpcomponents:httpclient:jar:4.1.1 pom.xml
/org.restlet.ext.openid line 1 Maven Dependency Problem
Missing artifact org.apache.httpcomponents:httpcore:jar:4.1 pom.xml
/org.restlet.ext.openid line 1 Maven Dependency Problem
Missing artifact org.freemarker:freemarker:jar:2.3.19 pom.xml
/org.restlet.ext.oauth line 1 Maven Dependency Problem
Missing artifact org.openid4java:openid4java-nodeps:jar:0.9.6 pom.xml
/org.restlet.ext.openid line 1 Maven Dependency Problem
Missing artifact org.restlet.jse:org.restlet.lib.org.json:jar:2.0
pom.xml /org.restlet.ext.oauth line 1 Maven Dependency Problem
Missing artifact xerces:xercesImpl:jar:2.9.1 pom.xml
/org.restlet.ext.openid line 1 Maven Dependency Problem
Missing artifact xml-apis:xml-apis:jar:1.3.04 pom.xml
/org.restlet.ext.openid line 1 Maven Dependency Problem


-----Message d'origine-----
De : Martin Svensson [mailto:msvens-***@public.gmane.org]
Envoyé : mercredi 2 mai 2012 08:06
À : code-s0N/mLB9wL+***@public.gmane.org
Objet : RE: Restlet Framework 2.2 - Build issues and Eclipse/OSGi
development

Just to be clear, what is the exact problem with the OAuth/OpenId extensions
(and how do I test those). When importing those modules and doing a "convert
to maven..." project everything works fine. Does the problem happen when you
do a "import existing java project?"

thanks,

martin

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=29567
46

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2957453
Andy Dennie
2012-05-15 16:36:28 UTC
Permalink
A request -- if you remove all of the pom.xml files, would it be possible to provide an alternate way to install the artifacts from my Restlet build into my local maven repo, after building with ant?

-Andy

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2960949
Shaun Elliott
2012-05-19 06:53:46 UTC
Permalink
I think this will work for you:

http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2963491
Andy Dennie
2012-05-19 20:56:09 UTC
Permalink
Thanks, Shaun. I actually started down the road of writing a script to install all the artifacts using the maven-install-plugin, but then after rummaging around in the ant build scripts a bit (I don't really know ant) and a certain amount of trial and error, I discovered that the pom files can still be generated in a repository-style directory structure with the following custom.properties file (e.g. for building 2.1-RC4):

major-number: 2
minor-number: 1
release-number:4
version-minor: ${major-number}.${minor-number}
release-type: RC
version-full: ${version-minor} Release Candididate
version-maven: ${version-minor}-${release-type}${release-number}
version-manifest-prefix: ${version-minor}.0.0.rc4-
verify: false
maven: true


... and then I could just write a small batch file to copy/paste the generated directory structure into my maven repo. Hopefully this capability will be retained in the ant build (presumably it would be needed to support installation into the repo at maven.restlet.org).

-Andy

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2963637
Loading...