You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by afs <gi...@git.apache.org> on 2017/11/17 15:12:08 UTC
[GitHub] jena pull request #312: Use top POM as parent.
GitHub user afs opened a pull request:
https://github.com/apache/jena/pull/312
Use top POM as parent.
And drop the Eclipse plugin setup(the plugin is retired).
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/afs/jena pom-parent
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/jena/pull/312.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #312
----
commit a192f88b3c10552b4ec7eeed9aba3fbfa01618af
Author: Andy Seaborne <an...@apache.org>
Date: 2017-11-17T15:01:32Z
Merge jena-project POM into root POM
----
---
[GitHub] jena issue #312: Use top POM as parent.
Posted by afs <gi...@git.apache.org>.
Github user afs commented on the issue:
https://github.com/apache/jena/pull/312
In SVN, it is more natural to checkout part of the tree and work on it.
In Git, you can only do that by messing around a bit.
It would stop cross-module changes. I see it has any real merit nowadays.
Keeping "Clone the repo; load IDE; code" clean is better.
---
[GitHub] jena pull request #312: Use top POM as parent.
Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:
https://github.com/apache/jena/pull/312
---
[GitHub] jena issue #312: Use top POM as parent.
Posted by afs <gi...@git.apache.org>.
Github user afs commented on the issue:
https://github.com/apache/jena/pull/312
Did some tidying up. There was some unnecessary items in some POMs, either because it was supposed to work with stand-alone modules, or just over specification.
---
[GitHub] jena issue #312: Use top POM as parent.
Posted by ajs6f <gi...@git.apache.org>.
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/312
I agree that Jena doesn't (and shouldn't have) a monolithic build, but do we want individual modules to be build-able separately? I'm not sure what the use case for that is...
---
[GitHub] jena issue #312: Use top POM as parent.
Posted by ajs6f <gi...@git.apache.org>.
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/312
What?
"standard techniques" is an ordinary Maven BOM.
---
[GitHub] jena issue #312: Use top POM as parent.
Posted by ajs6f <gi...@git.apache.org>.
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/312
Agreed, with SVN you deal in versions and there is a fairly natural mapping to modules, in DVC like git you deal with deltas and the module boundaries aren't as useful a way to organize change management.
We can always go to full on OSGi and run everything through dynamic services for full module decoupling! :stuck_out_tongue_winking_eye:
---
[GitHub] jena issue #312: Use top POM as parent.
Posted by afs <gi...@git.apache.org>.
Github user afs commented on the issue:
https://github.com/apache/jena/pull/312
The difference between "humor" and "humour".
The only thing I though of cutting was `<reporting>` as we don't use it in the build, given the long history of the codebase, none are really very useful (or maintained to check the reports even work). They can be called separately anyway.
The crux question is whether to have a simple, but mixed, POM structure vs more modules for more POMs driven by maven requirements.
Delivery POMs `apache-jena-*` reflect that Jena is not necessarily one tightly integrated "thing". If we go towards BOM and all that implies, we seem to be saying it is more tightly integrated.
That suggests to me leaving it fluid like it is, because adding new modules (contribution, code, not ones needed for maven design), with different statuses, different users, is better. A choice of BOM structure seems to be good for a project that is one thing.
So flexibility(future) vs separated concerns(now; assuming constant for the future).
In an enterprise project, changing the POM design as needs change is easier, because you can press the reset button, migrate and take the old offline. An open source project, via central.maven, keeps the old around.
---
[GitHub] jena issue #312: Use top POM as parent.
Posted by afs <gi...@git.apache.org>.
Github user afs commented on the issue:
https://github.com/apache/jena/pull/312
I was being frivolous!
For us, apps don't depend on the top POM, they depend on `apache-jena-libs` + whatever else they want.
We do need the top POM to have org.apache::apache` as parent to inherit the Apache std release setup. (The thought of writing and maintaining our own release process is unattractive to me.) So our top POM is internally focused, for better or worse.
A BOM has to be shared internally and externally so it is the top of the parent hierarchy. We _may_ be able to use `<scope>import` but whatever we have, if there is a super-BOM (beyond `apache-jena-libs`), we then have a new module ... in which case removing `jena-project` is the wrong thing to do at the moment.
No rush to make this change but aiming to change once would be better, especially if across a release.
---
[GitHub] jena issue #312: Use top POM as parent.
Posted by afs <gi...@git.apache.org>.
Github user afs commented on the issue:
https://github.com/apache/jena/pull/312
"standard techniques" being "don't look (until you have to)"?!
---
[GitHub] jena issue #312: Use top POM as parent.
Posted by ajs6f <gi...@git.apache.org>.
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/312
You got me with that dry English sense of humor. :wink:
> No rush to make this change but aiming to change once would be better, especially if across a release.
Good point. Let's do this gracefully instead of spastically.
We could look at some other ways to slice verbiage out of the top POM, although I admit I can't think of anything that would take as large a slice as `dependencyManagement`.
---