Restlet Framework 2.2 - Build issues and Eclipse/OSGi development

Discussion:

(too old to reply)

Jerome Louvel

2012-04-27 07:05:43 UTC

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">
I have to agree with David on much of this. 
 
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. 
 
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? 
 
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. 
 
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. 
 
-Tal 

 
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"><jerome.louvel-s0N/***@public.gmane.org></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&dsMessageId=2956647">http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&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">
I have to agree with David on much of this. 
 
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. 
 
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? 
 
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. 
 
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. 
 
-Tal 

 
<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&dsMessageId=2956647
">
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&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">
I have to agree with David on much of this. 
 
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. 
 
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? 
 
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. 
 
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. 
 
-Tal 

 
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"><jerome.louvel-s0N/***@public.gmane.org <mailto:lt%3Bjerome.louvel-s0N/***@public.gmane.org> ></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&dsMessageId=
2956647>
&dsMessageId=2956647">http://restlet.tigris.org/ds/viewMessage.do?dsForu
mId=7458
<http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=
2956647> &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">
This sounds like a very refreshing move to me. 
 
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. 
 
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.) 
 
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. 
 
-Tal 

 
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></style>
<div class="WordSection1">
Hi all,<o:p></o:p>
<o:p> </o:p>
Thanks for the feed-back, that’s really
helpful!<o:p></o:p>
<o:p> </o:p>
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.<o:p></o:p>
<o:p> </o:p>
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>
<o:p> </o:p>
In order to remove current ambiguities around
Maven, I propose to :<o:p></o:p>
1.       Remove the POM files automatically generated
from Git repository<o:p></o:p>
a.       only generate them for the Maven repository<o:p></o:p>
2.       Remove the PDE/MANIFEST files from Git
repository<o:p></o:p>
a.       the proper MANIFEST are separately generated
for the OSGi edition<o:p></o:p>
3.       Configure the Eclipse projects’ build path
configuration<o:p></o:p>
a.       to manage dependencies<o:p></o:p>
4.       Re-document the official way to develop with
Eclipse/NetBeans/IntelliJ<o:p></o:p>
a.       Git clone<o:p></o:p>
b.      import projects (need to add the .project files
and similar files to Git)<o:p></o:p>
c.       locate Ant build file<o:p></o:p>
d.      edit custom.properties<o:p></o:p>
e.      launch Ant targets<o:p></o:p>
<o:p> </o:p>
How does it sounds?<o:p></o:p>
<o:p> </o:p>
Best regards,<o:p></o:p>
Jerome<o:p></o:p>
--<o:p></o:p>
<a
moz-do-not-send="true" href="http://www.restlet.com/">http://www.restlet.com</a><o:p></o:p>
<a
moz-do-not-send="true"
href="http://twitter.com/#%21/jlouvel">http://twitter.com/#!/jlouvel</a><o:p></o:p>
<o:p> </o:p>
<o:p> </o:p>
<o:p> </o:p>
De :
<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>] De la
part de Tim Peierls 
Envoyé : mardi 1 mai 2012 22:54 
À : <a class="moz-txt-link-abbreviated" href="mailto:code-s0N/mLB9wL+***@public.gmane.org">code-s0N/mLB9wL+***@public.gmane.org</a> 
Objet : Re: Restlet Framework 2.2 - Build issues and
Eclipse/OSGi development<o:p></o:p>
<o:p> </o:p>
Agree with David and Tal in general. (Full
disclosure: I'm an Ant/Ivy user.)<o:p></o:p>
<div>
<o:p> </o:p>
</div>
<div>
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>
</div>
<div>
<o:p> </o:p>
</div>
<div>
--tim<o:p></o:p>
<div>
On Tue, May 1, 2012 at 2:44 PM, Tal
Liron <<a moz-do-not-send="true"
href="mailto:tal.liron-KRbUgwfp4vGAiRqxG6I7vAC/***@public.gmane.org"
target="_blank">tal.liron-KRbUgwfp4vGAiRqxG6I7vAC/***@public.gmane.org</a>>
wrote:<o:p></o:p> <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"> 
   I have to agree with David on much of
this. 
      
     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. 
      
     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? 
      
     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. 
      
     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. 
      
     -Tal 
    
    
   On 05/01/2012 01:27 PM, David Fogel wrote: 
   <blockquote 
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>" 
     type="cite"> 
     <pre wrap="">Hi Jerome, all-<o:p></o:p>
<div>
 
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<o:p></o:p>
</div>
Gradle ( <a
class="moz-txt-link-freetext" href="<a
moz-do-not-send="true" href="http://gradle.org/"
target="_blank">http://gradle.org/</a>"><a
moz-do-not-send="true" href="http://gradle.org/"
target="_blank">http://gradle.org/</a></a> ).
 Gradle is similar to Maven in some<o:p></o:p>
<div>
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<o:p></o:p>
</div>
<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>">&<a
moz-do-not-send="true"
href="mailto:lt%3Bjerome.louvel-s0N/***@public.gmane.org">lt;jerome.louvel-s0N/***@public.gmane.org</a>&gt;</a>
wrote: 
</pre> 
     <blockquote type="cite"> 
       <pre wrap="">Hi all,<o:p></o:p>
<div>
 
 
 
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<o:p></o:p>
</div>
update): <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>"><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></a><o:p></o:p>
<div>
<div>
 
 
 
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:<o:p></o:p>
</div>
</div>
<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>"><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></a><o:p></o:p>
<div>
 
 
 
This will allow fully dynamic usage of Restlet thanks to
OSGi, such as 
adding new applications or resources on the fly. 
 
 
 
Best regards, 
 
Jerome 
 
--<o:p></o:p>
</div>
<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>"><a
moz-do-not-send="true" href="http://www.restlet.com"
target="_blank">http://www.restlet.com</a></a> 
 
<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>"><a
moz-do-not-send="true"
href="http://twitter.com/#%21/jlouvel" target="_blank">http://twitter.com/#!/jlouvel</a></a> 
 
 
</pre> 
     </blockquote> 
     <pre wrap=""> 
------------------------------------------------------ 
<a class="moz-txt-link-freetext" href="<a
moz-do-not-send="true"
href="http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=2956647"
target="_blank">http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=2956647</a>"><a
moz-do-not-send="true"
href="http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=2956647"
target="_blank">http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&amp;dsMessageId=2956647</a></a> 
</pre> 
   </blockquote> 
 </body> 
</html> 
 
------------------------------------------------------ 
<a moz-do-not-send="true"
href="http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2956650"
target="_blank">http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2956650</a><o:p></o:p>
</div>
<o:p> </o: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. 

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. 

 

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.) 

 

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. 

-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