New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modularize the product #59

Closed
GoogleCodeExporter opened this Issue Mar 16, 2015 · 16 comments

Comments

Projects
None yet
1 participant
@GoogleCodeExporter

GoogleCodeExporter commented Mar 16, 2015

The product is already "modularized" in both the architecture overview and
the ant-scripts.

The only step missing is to build separate jar files (and maven-artifacts)
with correct dependencies for the different modules.

Modularization would also not force the product to have to choose between
TMAPI 1.0 and TMAPI 2.0, because these could be two separate modules.

Original issue reported on code.google.com by baard...@gmail.com on 5 Jul 2009 at 11:17

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Adding support for Java 1.6 will probably be easier if a modular approach is 
taken.
Just leave the code that only works in Java 1.5 in a separate module. If the 
code is
required for the product to work, we should provide an implementation for both 
versions.

Original comment by baard...@gmail.com on 5 Jul 2009 at 11:42

GoogleCodeExporter commented Mar 16, 2015

Adding support for Java 1.6 will probably be easier if a modular approach is 
taken.
Just leave the code that only works in Java 1.5 in a separate module. If the 
code is
required for the product to work, we should provide an implementation for both 
versions.

Original comment by baard...@gmail.com on 5 Jul 2009 at 11:42

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Modularization would be nice. I wanted to propose that, too.
Java 1.6 vs. 1.5: I think it's not worth to maintain both versions. Keeping 1.5 
for
the time being seems to be fine. 

Original comment by lars.he...@gmail.com on 6 Jul 2009 at 9:16

GoogleCodeExporter commented Mar 16, 2015

Modularization would be nice. I wanted to propose that, too.
Java 1.6 vs. 1.5: I think it's not worth to maintain both versions. Keeping 1.5 
for
the time being seems to be fine. 

Original comment by lars.he...@gmail.com on 6 Jul 2009 at 9:16

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Ideally, each module would have it's own directory
- enigne-api
- engine-mem
- engine-rdbms
- engine-tmapi
- ...
It would still be possible to create one ontopia.jar, though.

Original comment by lars.he...@gmail.com on 6 Jul 2009 at 9:23

GoogleCodeExporter commented Mar 16, 2015

Ideally, each module would have it's own directory
- enigne-api
- engine-mem
- engine-rdbms
- engine-tmapi
- ...
It would still be possible to create one ontopia.jar, though.

Original comment by lars.he...@gmail.com on 6 Jul 2009 at 9:23

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

In theory modularization is nice. In practice I'm not so sure. 

It adds conceptual overhead, because it means having to keep track of what the 
modules are and how to build each one, etc etc. It's not a showstopper, but the 
point is that there is a cost to splitting things up.

It's not clear that there is any demand for the modules as modules. Most of the 
value added by the product is through Ontopoly, the tolog tag library, the 
tolog 
query engine, and the Vizigator, and these don't make for good modules. It's 
not 
that you couldn't use the core engine to do useful stuff, but just that very 
few 
real projects, if any, would work directly with low-level components.

So I'm not convinced that this is a good idea. To me it seems like extra work 
adding 
a long-term cost with no benefit. But I'm open to argument.

Original comment by lar...@gmail.com on 7 Jul 2009 at 8:59

  • Added labels: Component-Build

GoogleCodeExporter commented Mar 16, 2015

In theory modularization is nice. In practice I'm not so sure. 

It adds conceptual overhead, because it means having to keep track of what the 
modules are and how to build each one, etc etc. It's not a showstopper, but the 
point is that there is a cost to splitting things up.

It's not clear that there is any demand for the modules as modules. Most of the 
value added by the product is through Ontopoly, the tolog tag library, the 
tolog 
query engine, and the Vizigator, and these don't make for good modules. It's 
not 
that you couldn't use the core engine to do useful stuff, but just that very 
few 
real projects, if any, would work directly with low-level components.

So I'm not convinced that this is a good idea. To me it seems like extra work 
adding 
a long-term cost with no benefit. But I'm open to argument.

Original comment by lar...@gmail.com on 7 Jul 2009 at 8:59

  • Added labels: Component-Build
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

I will argue that modules adds conceptual overview. However, I agree that
modularization adds overhead, so we should keep the number of modules to a 
minimum.

Therefore I propose that we keep the engine (or core) as one module, but 
separate the
applications that uses it:

ontopia-engine (or ontopia-core) (jar)
ontopoly (webapp)
vizigator (jar with main-method)
etc.

Original comment by baard...@gmail.com on 9 Jul 2009 at 11:31

GoogleCodeExporter commented Mar 16, 2015

I will argue that modules adds conceptual overview. However, I agree that
modularization adds overhead, so we should keep the number of modules to a 
minimum.

Therefore I propose that we keep the engine (or core) as one module, but 
separate the
applications that uses it:

ontopia-engine (or ontopia-core) (jar)
ontopoly (webapp)
vizigator (jar with main-method)
etc.

Original comment by baard...@gmail.com on 9 Jul 2009 at 11:31

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

I agree with Baard. That would be a good initial step.
We can decide later if we want a finer modularization. 

Original comment by lars.he...@gmail.com on 20 Jul 2009 at 5:23

GoogleCodeExporter commented Mar 16, 2015

I agree with Baard. That would be a good initial step.
We can decide later if we want a finer modularization. 

Original comment by lars.he...@gmail.com on 20 Jul 2009 at 5:23

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

I think the list of modules proposed by Baard makes sense, although it is 
incomplete.

There are at least two more .jars: ontopia-web (nav2, webed, etc) and 
ontopia-realm.

There are also more web applications. I think it's an open question whether we 
need .wars for them, or whether they should just be in the final distro.

I assume the full distro stays as-is.

Original comment by lar...@gmail.com on 27 Jul 2009 at 12:01

GoogleCodeExporter commented Mar 16, 2015

I think the list of modules proposed by Baard makes sense, although it is 
incomplete.

There are at least two more .jars: ontopia-web (nav2, webed, etc) and 
ontopia-realm.

There are also more web applications. I think it's an open question whether we 
need .wars for them, or whether they should just be in the final distro.

I assume the full distro stays as-is.

Original comment by lar...@gmail.com on 27 Jul 2009 at 12:01

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

I have looked a little into moving the web-releated sources out of 
ontopia-engine 
and into ontopia-web.
The folders nav2, webed and infoset look like they can be easily moved. 
But the tests are a little special, since they rely on AbstractWebedTestCase 
and 
other test infrastructure, that must be created in an own test artifact to be 
used 
by the sub modules. 
I have attached the diff I've created from some short hacking, but it may 
contain 
errors. The moving also has to be accepted by the main ontopia contributors!
Doing so means that a whole lot of web-related dependencies can be taken out of 
the 
ontopia-engine distribution.

Original comment by stig....@gmail.com on 19 Aug 2009 at 11:48

Attachments:

GoogleCodeExporter commented Mar 16, 2015

I have looked a little into moving the web-releated sources out of 
ontopia-engine 
and into ontopia-web.
The folders nav2, webed and infoset look like they can be easily moved. 
But the tests are a little special, since they rely on AbstractWebedTestCase 
and 
other test infrastructure, that must be created in an own test artifact to be 
used 
by the sub modules. 
I have attached the diff I've created from some short hacking, but it may 
contain 
errors. The moving also has to be accepted by the main ontopia contributors!
Doing so means that a whole lot of web-related dependencies can be taken out of 
the 
ontopia-engine distribution.

Original comment by stig....@gmail.com on 19 Aug 2009 at 11:48

Attachments:

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

one positive side-effect of modularization is, that also the dependencies for 
the
whole project are split up. By now, we have already > 35 MB of dependant jars, 
and it
is not an easy task (and tedious), to figure out, which one are really needed 
if you
just need the topicmaps engine (no webapp stuff), and providing a 40 MB 
distribution
to clients is not very convenient in this regard.

So I am supporting to split up the project in at least the modules proposed by 
baard.
I am also willing to volunteer on creating a maven structure for this, as I have
already experience in doing this for other projects of similar size.

Original comment by thomas.n...@gmail.com on 28 Sep 2009 at 12:30

GoogleCodeExporter commented Mar 16, 2015

one positive side-effect of modularization is, that also the dependencies for 
the
whole project are split up. By now, we have already > 35 MB of dependant jars, 
and it
is not an easy task (and tedious), to figure out, which one are really needed 
if you
just need the topicmaps engine (no webapp stuff), and providing a 40 MB 
distribution
to clients is not very convenient in this regard.

So I am supporting to split up the project in at least the modules proposed by 
baard.
I am also willing to volunteer on creating a maven structure for this, as I have
already experience in doing this for other projects of similar size.

Original comment by thomas.n...@gmail.com on 28 Sep 2009 at 12:30

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

is there any progress on this issue? I will have to do this anyways for a 
project I
work on, so we could coordinate more on these things.

I was thinking about the following modules:

 - ontopia-core (interfaces)
 - ontopia-io (all the importer/exporters, could also be in core)
 - ontopia-engine-memory
 - ontopia-engine-rdbms
 - ontopia-fulltext
 - ontopia-tools (cmdline tools, db2tm, could also be in core)
 - ontopia-viz (visualization stuff)
 - ontopia-query-tolog
 - ontopia-query-tolog-basic
 - ontopia-query-tolog-rdbms
 - ontopia-webnav (contains nav and webed packages)
 - ontopia-webapp (as a first step, could later be further split up in omnigator,
ontopoly)

The tolog split-up is artificial, could also be one module, that is dependant on
ontopia-engine-memory and ontopia-engine-rdbms.

Original comment by thomas.n...@spaceapplications.com on 25 Nov 2009 at 9:38

GoogleCodeExporter commented Mar 16, 2015

is there any progress on this issue? I will have to do this anyways for a 
project I
work on, so we could coordinate more on these things.

I was thinking about the following modules:

 - ontopia-core (interfaces)
 - ontopia-io (all the importer/exporters, could also be in core)
 - ontopia-engine-memory
 - ontopia-engine-rdbms
 - ontopia-fulltext
 - ontopia-tools (cmdline tools, db2tm, could also be in core)
 - ontopia-viz (visualization stuff)
 - ontopia-query-tolog
 - ontopia-query-tolog-basic
 - ontopia-query-tolog-rdbms
 - ontopia-webnav (contains nav and webed packages)
 - ontopia-webapp (as a first step, could later be further split up in omnigator,
ontopoly)

The tolog split-up is artificial, could also be one module, that is dependant on
ontopia-engine-memory and ontopia-engine-rdbms.

Original comment by thomas.n...@spaceapplications.com on 25 Nov 2009 at 9:38

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Peter-Paul from Morpheus has also been working on this. I'll notify him so that 
we 
can all coordinate here.

In general, I think the rule should be: the fewer modules, the better.

How about:
- ontopia-core (interfaces + io)
- ontopia-backend-memory
- ontopia-backend-rdbms (also includes rdbms-tolog)
- ontopia-fulltext
- ontopia-tools
- ontopia-viz
- ontopia-tolog (basic)
- ontopia-webnav
- ontopia-webapp
- ontopia-classify

This should reduce the list of modules at least minimally. :)

Original comment by lar...@gmail.com on 25 Nov 2009 at 9:44

GoogleCodeExporter commented Mar 16, 2015

Peter-Paul from Morpheus has also been working on this. I'll notify him so that 
we 
can all coordinate here.

In general, I think the rule should be: the fewer modules, the better.

How about:
- ontopia-core (interfaces + io)
- ontopia-backend-memory
- ontopia-backend-rdbms (also includes rdbms-tolog)
- ontopia-fulltext
- ontopia-tools
- ontopia-viz
- ontopia-tolog (basic)
- ontopia-webnav
- ontopia-webapp
- ontopia-classify

This should reduce the list of modules at least minimally. :)

Original comment by lar...@gmail.com on 25 Nov 2009 at 9:44

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

I just committed r684 that introduces an initial Maven structure. It leaves the 
existing code directory in place and 
uses specific includes and excludes within the various POMs. My suggestion is 
to keep this approach while 
setting up additional modules. Once this is stable and accepted, we can migrate 
the actual code files into 
separate Maven directory structures. Please read my notes in the attachment. 
I'm happy to see collaboration and 
extensions on the initial work I've done.

Original comment by p.kruijsen on 25 Nov 2009 at 10:09

Attachments:

GoogleCodeExporter commented Mar 16, 2015

I just committed r684 that introduces an initial Maven structure. It leaves the 
existing code directory in place and 
uses specific includes and excludes within the various POMs. My suggestion is 
to keep this approach while 
setting up additional modules. Once this is stable and accepted, we can migrate 
the actual code files into 
separate Maven directory structures. Please read my notes in the attachment. 
I'm happy to see collaboration and 
extensions on the initial work I've done.

Original comment by p.kruijsen on 25 Nov 2009 at 10:09

Attachments:

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Looks good. I do get compile errors on missing TMAPI classes when I try to run 
"mvn 
clean package" though.

Original comment by indiapaleale@gmail.com on 26 Nov 2009 at 10:47

GoogleCodeExporter commented Mar 16, 2015

Looks good. I do get compile errors on missing TMAPI classes when I try to run 
"mvn 
clean package" though.

Original comment by indiapaleale@gmail.com on 26 Nov 2009 at 10:47

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Original comment by qsieb...@gmail.com on 30 Sep 2010 at 9:57

  • Added labels: Management-Maven

GoogleCodeExporter commented Mar 16, 2015

Original comment by qsieb...@gmail.com on 30 Sep 2010 at 9:57

  • Added labels: Management-Maven
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Fixed by r2090

Original comment by qsieb...@gmail.com on 17 May 2011 at 10:54

  • Changed state: Fixed

GoogleCodeExporter commented Mar 16, 2015

Fixed by r2090

Original comment by qsieb...@gmail.com on 17 May 2011 at 10:54

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Original comment by qsieb...@gmail.com on 27 Jan 2012 at 10:38

  • Added labels: Release5.2.0

GoogleCodeExporter commented Mar 16, 2015

Original comment by qsieb...@gmail.com on 27 Jan 2012 at 10:38

  • Added labels: Release5.2.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment