That is a good idea, maven can call ant to execute tasks. The jars are
available in the maven repository and should therefore not be to hard to
make available to the ant build. Would be nice to have an idea of the amount
of scripts that we need to alter to make this happen. I also see a lot of
shell scripts that might need attention if we change this.
- Jettro
On Mon, Aug 23, 2010 at 4:52 PM, karl.wri...@nokia.com wrote:
Re: build preferences
Continuing to have an ant build is actually pretty important for some modes
of delivery. I'm specifically thinking of debian and Ubuntu packaging here.
Maven does not work well with these packaging schemes because it's too
all-encompassing. We therefore need a way of doing builds locally, without
pulling things down from a mirror.
My original thought was that we'd have multiple layers - ant being the
most basic, with a maven wrapper available to pull down what the ant build
needed, and have the maven build call ant underneath. I don't know how
realistic that is, but it does solve all the problems if it can be done that
way.
Karl
From: jettro.coenra...@gmail.com [mailto:jettro.coenra...@gmail.com] On
Behalf Of ext Jettro Coenradie
Sent: Monday, August 23, 2010 10:43 AM
To: connectors-dev@incubator.apache.org
Subject: Re: improving the build
I am looking at the current project structure. If we want to make another
build tool available I think we need to change the directory structure. I
tried to place a suggestion in an image. Can you please have a look at it.
If we agree that this is a good way to go, than I will continue to work on a
patch. Which might be a bit hard with all these changing directories, but
I'll do my best to at least get an idea whether it would be working.
So I have three questions:
- Do you want to move to maven or put maven next to ant?
- Do you prefer another build mechanism [ant with ivy, gradle, maven3]
- Do you have an idea about the amount of scripts that need to be changed
if we change the project structure
The image of a possible project layout (that is based on the maven
standards) is attached to the mail
Jettro
On Mon, Aug 16, 2010 at 3:12 PM, Jettro Coenradie
jettro.coenra...@gridshore.nlmailto:jettro.coenra...@gridshore.nl
wrote:
We could use something like profiles in maven. That way you can easily
configure which projects to compile and which not. That would include tests.
I will have a look at it and come up with a proposal.
On Mon, Aug 16, 2010 at 2:49 PM, karl.wri...@nokia.commailto:
karl.wri...@nokia.com wrote:
Re maven: There is a wiki page describing the Maven dependencies; somebody
needs to tackle this. If you want to volunteer, we'd love to hear your
proposal. However, please remember that you really must be sure to retain
the connector conditional compilation structure as is currently in place,
for license reasons.
Re unit tests: The Junit test code was actually placed carefully based on
the above considerations. In other words, you can't run a test that
requires connectors x,y,z unless those connectors have actually been built.
Similarly, you may think in terms of testing a specific connector by
including tests for that connector, but those tests cannot use any OTHER
connectors or you will break the build, which is why any tests that use
multiple connectors must be at the module level.
Karl
-Original Message-
From: jettro.coenra...@gmail.commailto:jettro.coenra...@gmail.com
[mailto:jettro.coenra...@gmail.commailto:jettro.coenra...@gmail.com] On
Behalf Of ext Jettro Coenradie
Sent: Monday, August 16, 2010 8:21 AM
To: connectors-dev@incubator.apache.orgmailto:
connectors-dev@incubator.apache.org
Subject: improving the build
Hi,
I think the current download is pretty big. Is there is good reason that we
do not use something like maven. Or at least, if you do not like maven, ivy
to share dependencies between projects. Also enforces you to use libraries
that are generally available.
I would also love to have the (unit)tests closer to the actual code, hard
to
locate the tests at the moment
Would like to hear the thoughts of the developers
regards
--
Jettro Coenradie
http://www.gridshore.nl
--
Jettro Coenradie
http://www.gridshore.nl
--
Jettro Coenradie
http://www.gridshore.nl
--
Jettro Coenradie
http://www.gridshore.nl
