I'd strongly advise against it. Having single project - single binary
relationship makes a project easier to comprehend and manage.
Also, having small, focused and cohesive modules is IMO the whole point
of modularity. By extension, a complex application will have many of them.
There are ways to cope with that in Eclipse - Working Sets (which may be
used as top level entries in project explorer) for starters, and also
Mylyn Task focued UI.
In order to overcome complexity you need to embrace it. Attempts to hide
it will backfire one way or the other.
regards,
Rafał
On 06/28/2012 11:09 AM, Angelo van der Sijpt wrote:
Hi list,
Sounds like a good idea to me. I would definitely like to reduce the number of
projects: we have a number of api-only projects, with Maven's
one-artifact-per-project setup, it would be nice to categorize projects by what
they do, and 'carve up' the class space in that project in any way we see fit.
Also, I have been using BndTools for quite a while now, and really like the
developer experience.
That's a +1 from me!
Angelo
On Jun 28, 2012, at 10:39 AM, Jean-Baptiste Onofré wrote:
Hi Marcel,
as discussed this morning, it sounds like a good idea. I took a look on
BndTools and it's interesting, fast, and stable (regarding the small tests that
I did ;)).
I would be glad to help around that !
Regards
JB
On 06/28/2012 10:37 AM, Marcel Offermans wrote:
Hi all,
When ACE entered the incubator a few years ago, we were using a highly
customized Ant based build. At that time, as a community we decided that it
would be easier to get started with ACE if we moved the build to Maven.
Now, I think we have arrived at a point where we need to revisit that decision
and consider moving to BndTools [1].
Probably the biggest reason for migrating from Maven to BndTools is to speed up and simplify development. In
case you're not familiar with BndTools, it is an Eclipse plugin that provides an OSGi development environment
based on Bnd. Compared to other environments, it is really fast. As soon as you hit "save" on one
of your source files, a new version of your bundle is created and deployed, making any changes almost
"instant". Bundles themselves are defined using "bnd" files and the plugin provides nice
editors for those, as well as many different abstractions to talk to external repositories through OBR. There
are many other advantages, such as tooling to help us correctly use semantic versioning throughout our
project and easy ways to run and debug different bundle configurations. Headless builds are supported, as are
unit and integration testing. An interesting twist is that deploying directly to ACE itself is also
supported, so we as a project integrate nicely with this environme
nt.
Another reason to move is that it could make our release process a lot simpler. Recent discussions within Apache about
what constitutes an official release have emphasized that only source releases are "official" Apache releases
and that those are the ones we should vote on. Afterwards we can obviously still make binary releases available, and I
think in the case of ACE we should. During our releases in the incubator we have tried to strike a balance between
doing "big bang" and "component" releases, setting up everything in such a way that we could do
both. This has proven to be very complicated and doing releases was painful. With BndTools we can create one source
archive that can be used "out of the box" to build everything and since this embeds all bundle and package
versions we can decide to only bump those if something actually changes. For convenience we can then still provide both
separate artifacts for Maven as well as shrink-wrapped binaries that can be used out of the box
.
So, the main point I'd like to discuss is, what is your view on moving to
BndTools?
Greetings, Marcel
[1] http://bndtools.org/
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
