ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: [DISCUSS] Moving the build to BndTools
Date Mon, 02 Jul 2012 06:54:51 GMT
Hello all,

As this discussion seems to have ended, it's time to wrap it up. I've seen some enthousiastic
reactions and a few critical notes. All in all I think we should proceed, and I agree with
Paul that he first step in the process probably is to keep the project structure intact and
do a 1 on 1 migration. When that works, we can review if it makes sense to group certain bundles
in a single project or not.

To get the work started, I've created an issue that will group all required subtasks:

Greetings, Marcel

On Jun 28, 2012, at 14:25 PM, Paul Bakker wrote:

> I have been using BndTools for about a year now on a large project. It works very well,
and the development experience is much better/faster compared to Maven. For anyone who tried
BndTools when it was still in alpha/beta versions; please try again, a lot has improved and
it is very stable now. I'm strongly in favor of moving to BndTools.
> I don't see any reason to keep using Maven when we migrate to BndTools. Offline builds
with the generated ANT builds work very well from a CI server. Most of what you need works
out of the box, and in my experience it's actually easier to do very specialized release builds
from ANT then for Maven. IMO the only benefit that Maven offers is a way to manage dependencies
using repositories, which is very important,  but the repositories BND/BNDTools use do the
same. I'm in favor of dropping Maven all together.
> On the subject of re-structuring the projects I think we should decide as a next step.
BndTools offers some interesting possibilities to group projects together in the IDE, but
we don't have to use that if we don't want to. Maybe we could first migrate the projects without
making structural changes, and start moving code after that.
> Paul
> On Jun 28, 2012, at 7:48 , Rafał Krzewski wrote:
>> Keeping the POMs for CI/release builds AND running the application live from Eclipse
workbench at the same time is a possibility.  However, if you scrap Maven build, and use Bndtools,
you'll have to use Ant for "offline" builds. You could also hack together a build using python,
make or bash. Either way, I see it as a huge step back from what you have now. In my opinion
well laid out Maven build is a great asset for long term maintainability of a project. If
you see it as a burden only, it's your call. Use whatever works best for you. After all you
will live with the consequences of either choice you make anyway :)
>> regards,
>> Rafał
>> On 06/28/2012 01:21 PM, Marcel Offermans wrote:
>>> We are aware of how to currently build the project with Maven (using m2e and
related tools). The point is that this way of developing and building the project is a lot
slower. For example, if I now want to change a single Java file in one project, I then need
to manually rebuild that project, then rebuild the assembly, and if I had for example the
ACE server running, I need to either update that bundle myself, or even worse, restart the
whole application. All of these steps can no doubt be automated if you spend enough effort
with Maven, but this stuff works out of the box with BndTools, which is why I proposed the
whole move.
>>> So we do not intend to keep all the pom files that Maven requires but instead
just create a few bnd files with the bundle definitions and let BndTools do the rest.
>>> Greetings, Marcel
>>> On Jun 28, 2012, at 12:36 PM, Rafał Krzewski wrote:
>>>> On 06/28/2012 11:45 AM, Tang Yong wrote:
>>>>> Hello Rafal,
>>>>>> From my experience, Bndtools + maven-bundle-plugin combination works
>>>>>> quite well. You don't need to migrate away from Maven to Ant in order
>to use Bndtools.
>>>>> Real Case is that:
>>>>> how to import the maven-built large project into bndtools including mave
n repo's setting.
>>>> First off, I assume that the project is OSGi application built using maven-bundle-plugin.
>>>> You should use fairly new Eclipse - 3.8 or 4.2, m2e 1.1, maven-bundle-plugin
2.3.6+ and current Tycho m2e connector. The last is quite counter-intuitive, but it is in
fact necessary.
>>>> With this set of tools, you should be able to import the project into eclipse
workspace using "Import existing Maven projects into Workspace" and it should build cleanly.
If the build is using non-standard plugins you might run into m2e connector problems. There
are different solutions, depending on what plugins are in use. I can offer some assistance
here, too.
>>>> Once you have the all the dependencies resolved, and all the sources building,
you can introduce Bndtools into the mix. You should create bnd.bnd files in each module an
move the configuration of BND from maven-bundle-plugin section to that file, and add Bndtools
project nature to your project. After this is done, the modules will appear in Bndtools "workspace"
repository. Once you have the Workspace repository populated, you can set up some run descriptors
to spin up an OSGi framework and run your appplication straight from workspace. Your bundles
will be updated in the framework on Save action on and editor, which is allows for really
smooth work flow.
>>>> Please note that you should be using m2e provided classpath container for
compile-time dependencies in Eclipse. This ensures that the project will build the same way
both in Eclipse and outside it (on CI server etc). The runtime classpath is managed by Bndtools,
and is composed of bundles from OBR repositories. Maven repositories can be exposed as OBR
repositories in several ways, Nexus OSS + OBR plugin being probably the most flexible, but
there are simpler zero-investment solutions - repository.xml can be generated with OSGi Bindex
tool, or maven-bundle-plugin.
>>>> regards,
>>>> Rafał
>>>>> BTW: which version of bndtools are you using? Version 1.0.0?
>>>>>> mine :) I can share some experiences/tips if anyone is interested.
>>>>> I want to know very much! Thanks!
>>>>> -Best Regrads
>>>>> -Tang

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message