[
https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901777#action_12901777
]
Karl Wright commented on CONNECTORS-92:
---------------------------------------
bq. As a response to the remark from Karl
(1) Breaking up modules and putting pieces of that all over the place
I do not think they are all over the place, maybe I am thinking wrong about the
modules part, but for me modules is not really clear. At the moment we have
documentation, modules and tests. I suggest a slightly more separated mode
with: documentation, integration-tests, framework, connectors and environment.
The only change is to move some stuff from modules into a new part environment
en move the other parts of modules one level up.
Each thing under modules is something you'd want to build separately, which is
why I chose the arrangement in the first place. If I were deploying these on a
debian system, each would be its own package. That is, each connector would
necessarily be its own package, as would mod-authz-annotate, and
java-environment. Indeed, java-environment was originally a debian package
that was part of the LCF software grant and has not been modified even to
build, because it in effect represented a Debian java deployment framework
rather than actual code. Same thing with postgres-config, except that was for
postgresql configuration under Debian. Furthermore, mod-authz-annotate is C,
and probably cannot be built under maven (or do I have that wrong?)
Therefore, for a maven build we should plan on building the following as
SEPARATE maven deliverables/targets:
- (1) Each connector
- (2) The framework
If there is a way to build C stuff under maven, then this too should be a maven
deliverable/target:
- (3) mod-authz-annotate
These should exist in the tree but be ignored for now, since they are not
applicable to maven at all:
- (4) java-environment
- (5) postgres-config
bq. (2) Taking jetty-runner out of framework
I do not think that Jetty is part of your framework, you create war files and
give the option for an easy start using Jetty. But maybe I am wrong.
I set the jetty example and runner up so that they do not have explicit
dependencies on any individual connectors, and thus they're built as part of
the framework, which they DO have a dependency on. A case could be made for
having these be separated into their own module-level component, in which case
they'd also be their own maven deliverable.
bq. (3) Introducing a "src" directory under each of the framework components
At the moment when running ant. You get a lot of folders of which it is not
always easy to understand whether they are original source folders or not. That
is why maven comes with a clear separation of src, generated-source and target
for other generated content. To my opinion this makes it easier to see what is
under version control and what is not.
Check the maven page for more explanation.
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
I will read the page. It seems to me that we'd need to agree what the maven
deliverables would be before we can decide where the "src" directory goes. If
the framework is a component all by itself (and I think it should be), then
naturally the structure would be "modules/framework/src/..." instead. Does
maven allow multiple jars in a deliverable? That would be a necessary
condition.
bq. (4) Moving the tests so far away from the code they are related to
I am not sure if I was clear enough on this. In the original code base a test
folder is available next to modules. For unit tests I would keep them as close
as possible to the source code. Therefore we have the src/main and src/test in
the same module. The integration tests are another beast. Usually a lot of
environmental setup needs to be done, they take longer, and you might want to
store them in a different folder so you can run them all at once. Another
option would be to add them next to the unit tests in a different folder
[src/main, src/test/ and src/integration-test] or use a different naming
scheme. **Test.java and **IntegrationTest.java That way you can folder them out
as well and use the maven lifecycle to decide whether to run unit test or both
unit and integration tests.
As of right now, there are three kinds of tests in the system: Unit tests
(which are checked in in the module they are to test), integration unit tests
(which are checked in at the "modules" level), and full integration tests that
are a legacy of the LCF code grant (which are checked in in the "tests"
directory above the modules level). The full integration tests are not
executed but were meant to furnish the rudiments of a test plan,as well as
useful bits for manipulating repositories themselves during test processes, and
thus must be considered "reference material" at this time. The "documentation"
directory above the modules level has a similar history.
I put the integration unit tests under "modules" because the main build script
was checked in at the "modules" level, and it needs to run those tests. If we
move the mail build script higher up, the integration unit tests can move up
also.
bq. As for the part where we need ant to make certain deliveries, we can still
do that. Than you have two options, or run the ant command to make these
deliverables yourself, or add them to the package lifecycle stage of maven. It
is not hard to call ant from maven. You could even create the mother of all ant
build file that calls maven to build the framework and the conenctors.
Let's settle the basic questions first, and then revisit the best way to do the
maven build.
> Move from ant to maven or other build system with decent library management
> ---------------------------------------------------------------------------
>
> Key: CONNECTORS-92
> URL: https://issues.apache.org/jira/browse/CONNECTORS-92
> Project: Apache Connectors Framework
> Issue Type: Wish
> Components: Build
> Reporter: Jettro Coenradie
> Attachments: Screen shot 2010-08-23 at 16.31.07.png
>
>
> 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 issue
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
