On Sun, Dec 13, 2009 at 11:20 AM, Kurt T Stam <[email protected]
<mailto:[email protected]>> wrote:
Hi guys,
I have created a wiki page where we can discuss the build design.
Do we have a wiki for ODE?
We do, there's a Confluence committer-only one for the site (as it
gets live every night) but there's also a MoinMoin instance that's
open to all, you just need to signup:
http://wiki.apache.org/ode/
Somewhat outdated but should be good enough for the purpose of
creating isolated pages. It could use some cleanup as well anyhow. I'd
rather avoid wiki fragmentation with some pages being at Apache and
others being at JBoss.
Thanks,
Matthieu
I was not able to find it, so I created this one for now:
http://community.jboss.org/wiki/MavenBuildDesignApacheODE. I'm
thinking we target the ODE-2.0 trunk? We can always decide to port
back to ODE-1.3.x once things are working?
What do you think about using this thread to discuss and then add
to the wiki page as we go along? As Jeff mentioned in
http://issues.apache.org/jira/browse/ODE-729 We now have a branch
with the latest ODE code: the work branch is hosted at:
http://anonsvn.jboss.org/repos/riftsaw/branches/ODE/ODE-2.0-maven/
or https://svn.jboss.org/repos/riftsaw/branches/ODE/ODE-2.0-maven/
(for committers). Looks like we have Jeff, Daniel, Greg and myself
who are interested to work on this. Rafal I heard from Jeff you
where interested also? Anyway if anyone else would like to give a
hand on this, please feel free to join in.
I think we should map out what artifacts are created in each
module, and map out how the rakefile would map to a maven based
build. IMO we should try to keep it as simple as possible as to
make it very straightforward to maintain it, and we should
document the build process as we go along.
Opening the floor for further discussion..
Cheers,
--Kurt
Kurt T Stam wrote:
Sounds good, I'll talk to Jeff, Greg and whoever else is
interested, and see if we can work on this together. Since
neither one of us has commit rights yet, we may just work on a
copy of the ODE-2.0 trunk in the Riftsaw SVN until things
start working, and we can then supply the patch back.
--Kurt
Alexis Midon wrote:
As a developer, my experiences with Maven were painful and
time consuming.
Maven gets in your way anytime you need to do a task as
simple as moving a
file, assuming you find a plugin for it. If you don't,
well, you have to
write some ant tasks or your own plugin... where a simple
ruby line or a
nicely integrated Rake task does the job.
As an ODE developer, I enjoy not to have to deal with xml
files all over the
place, plugin release management, transitive dependencies.
And I love fast,
repeatable and consistent builds. Personal tastes I guess...
Anyway we could discuss endlessly about Maven pros and cons :)
If you guys want to contribute a Maven build, that's fine.
Your pom's will
be much welcomed. You could imagine having both as long as
it does not break
the current build and that we have people to maintain them.
On Wed, Dec 9, 2009 at 3:23 PM, Greg Lucas
<[email protected] <mailto:[email protected]>> wrote:
My concerns are related to the general adoption of
Maven and the growing
set of tools that support it. I would suspect that:
- ODE developers and users are working with multiple
projects.
- Many (most?) potential ODE developers/users are
already using maven; or
are investing in it because of other projects.
- Some of those potential developers/users have no
prior experience with
Ruby and no other requirement to invest in it.
My specific scenario involves adding ODE to an
existing environment that is
used to build/test multiple projects (Apache and
otherwise - including
Karaf, ServiceMix, CXF, Camel, etc). All of these
projects have Maven2
builds. The incremental cost of adding a new
maven-based project to the
environment is substantially lower than adding
something new. I have seen
customers maintaining similar environments to build
open-source and in-house
projects, so this is not unique.
Some pain points:
1. Getting ruby/buildr running builds/tests on
multiple platforms and JVMs
(Win/Linux/Unix, 32/64-bit, JDK 1.5/1.6, etc)
When I started looking at this ODE 1.x required native
ruby (installed &
compiled for various platforms) and buildr 1.2.10. I
had numerous issues
getting that to work - the buildr gem wouldn't install
because of circular
dependencies, the build failed to run with jdk 1.6,
etc. Getting the 1.x and
trunk branches on the latest buildr version helps, as
does using jruby
(although I have an sftp upload issue with jruby).
2. Releases that span multiple projects need to ensure
consistent 3rd-party
dependencies.
Representing dependencies with a common model is
required to do any
meaningful cross-project validation. I'd echo Kurt's
point that projects
that want to consume ODE artifacts are more likely to
know the pom model.
While creating the OSGi bundle for the JBI component I
used svn blame to
figure out why some transitive dependencies were being
used (some no longer
necessary), rather than simply being able to view the
dependency tree.
Eclipse and IntelliJ understand poms and make it easy
to import maven
projects. Buildr can generate IDE-specific projects,
but it's not quite the
same: in IntelliJ I can also grab the pom for a
dependency, create a module,
and start building against that module rather than the
jar in my local repo.
3. There are many existing plugins and tools to solve
common problems
For example adding an OSGi bundle for ODE could use
the maven-bundle-plugin
which leverages the maven dependency model to do
things that bnd does not -
e.g. dealing with test and provided scopes. Having
direct access to Ruby
provides lots of flexibility, but in many cases I'd
rather use an existing
stable tool than write my own.
Individual concerns can be addressed, I'm happy to
learn more ruby and
contribute to buildr. But my overall experience so far
has been spending
just as much time with the build system as with ODE
itself - effort toward a
likely result of one project out of many that uses its
own dev
infrastructure and requires continual special-case
handling.
On Wed, 09 Dec 2009 10:54:40 -0500, Kurt T Stam
<[email protected] <mailto:[email protected]>>
wrote:
I was going to comment on
http://issues.apache.org/jira/browse/ODE-729,
but I think having discussions
on the mailing list works better then in jira. So
I'm going to add this
thread and add 2 more pain-points
1. There can be issues between ruby and java if
somehow the bit versions
used are out of sync (32 vs 64 bit). It simply
blows up without much detail
as to what happened. So much easier to use 1
environment (java). Yeah I know
you will tell me to use jruby.
2. Adhereing to an Apache standard build tool and
environment. Maven
forces a common layout, build and release process.
3. Tooling support. I can get my IDE setup easily
using a maven-eclipse
plugin.
4. Dependency management. Projects that consume
ODE (i.e. Riftsaw) need to
know the dependency, compile, runtime and test.
Maven does this for me and
it makes it easy for me to display it, again
though plugins into my IDE.
5. I have a hard time running multiple buildr
versions. I have 1.2.10
working now, but as soon as I also install 1.3.x,
then 1.2.10 breaks as some
gem dependency gets skrewed up. Which forces me to
painstakingly remove gems
until 1.2.10 works again.
6. I like a minimal build; have it just work, by
convention of the layout
of the project, maven done right does not
'get-in-the-way', and I only have
to worry about bugs in one build tool; not in two.
7. Check the mailing list to see how many people
having issues getting
their build going.
thx,
--Kurt
Jeff Yu wrote:
here are couple issues that I had (before I
talked about my current task)
1. I knew buildr is quite new, but the
adoption is really an issue. The
adoption means the plugins, and the work that
I need to do. I remembered
that one task that I was working on is to try
to push the artifacts into
maven snapshot repository, which is webdav
protocol. Simply I just
couldn't
find a 'just works' plugin for me to do so. In
the end, I used the
maven-ant-task to do the publish, as I had a
problem by using buildr
against
our repo, I tried the way as Alex Boisvert
pointed out in buildr
maillist,
couldn't work against our repo, quite frustrating.
2. It requires developer to learn Ruby. I know
it sounds interesting to
learn a new language, but sometimes I just
want to make my build system
just
works and easily been understood.
3. It also depends on specific library
version. If you go to the
.gem/ruby/1.8/gems/buildr-1.3.5/addon/buildr
directory, take xmlbeans.rb
as
an example, it depends on a specific xmlbeans
version, what if I used a
different version in my own project, does it
require me to update this to
make these version consistent. same goes to
the hibernate.rb etc.
4. Don't have enough documentation for how to
write an addon, how did the
buildr work underlie, like I still didn't
understand in the dao-hibernate
module, how the mvn-hibernate.xml was used
when I run 'buildr publish'.
.....
other comments inline.
On Wed, Dec 9, 2009 at 9:12 AM, Alexis Midon
<[email protected] <mailto:[email protected]>>
wrote:
Hi Jeff,
What are your pain points?
