[
https://jira.duraspace.org/browse/DS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24563#comment-24563
]
Kevin Van de Velde commented on DS-981:
---------------------------------------
[22:05] <kompewter> [ https://jira.duraspace.org/browse/DS-981 ] - [#DS-981]
Created a DSpace API module to contain api changes - DuraSpace JIRA
[22:06] <tdonohue> oh, I remember this one....about creating a new
[dspace]/modules/api/ folder for API overlays.
[22:08] <KevinVdV> It appears my patch is a bit out of date
[22:08] <tdonohue> anyone have thoughts/opinions on this idea? does this seem
useful to others?
[22:08] <sands> seems like a reasonable and non-disruptive change.
[22:08] <PeterDietz> ohh, I haven't seen this.. When I was following the module
overlay method, this would have been very useful to be in there.
[22:09] *** ryscher (ae61f77a@gateway/web/freenode/ip.174.97.247.122) joined
[22:09] <hpottinger> I think having a clear place to override API stuff would
be great, and +1 PeterDeitz
[22:09] <KevinVdV> Well the thought behind it is that it would be nice general
place to place all dspace-api code changes
[22:09] <PeterDietz> (I've since switched to not following module overlays),
but I would be supportive of this
[22:09] <mdiggory> hello, Kevin just kicked me to wake me back up.
[22:10] <mhwood> 0, I don't use overlays but the proposal seems sensible.
[22:10] <tdonohue> The only (very slight) concern I have is that technically
this doesn't "overlay" the full dspace-api (in that I don't think it lets you
overlay the dspace-api.jar in [dspace]/lib/ used for command-line). But, I
still like the idea of putting API changes in one place so that they are
inherited by all webapps
[22:11] <mdiggory> correct, it is a place to put customized addon code.
[22:11] <tdonohue> so, that's more of an "advertising" concern. We just need
to be very clear about where code/files placed in [dspace]/modules/api/ ends up.
[22:12] <aschweer> tdonohue: that would cause problems with custom embargo
lifters and the like, wouldn't it? definitely something to advertise then
[22:13] <tdonohue> one last question: should it then be called something
besides "api"? Is the name [dspace]/modules/api/ OK, or should it be named
something else? (I'm on the fence here)
[22:13] <mdiggory> I think the general point here that is of concern is... when
you create custom addons that are just for your local use, you either need to
create this kind of project to share them across the webapps, or dump your code
into dspace-api
[22:14] <mhwood> [dspace]/modules/global ?
[22:14] <mdiggory> the objective of the api project is to make it so that
implementers don't need to edit poms to get simple java code into lib and
webapps.
[22:14] <PeterDietz> I would say changes that I make to dspace-api, are
generally overall improvements that we ought to contribute back upstream, so
hopefully they don't dangle as modifications for too long
[22:15] <tdonohue> mdiggory -- totally agree with the reasons behind this. I
think it's a good addition. I'm just questioning whether the name "api" would
make people assume they are also updating "dspace-api.jar" in [dspace]/lib/
[22:15] <mdiggory> is it a better practice to package your own changes and
classify them accordingly modules/addon1 modules/addon2.... or promote putting
all in one modules.
[22:15] <sands> would calling it dspace-api be a more descriptive name?
[22:16] <sands> it seems worth including to me, as one doesn't have to use it
if their practice doesn't agree with it. it's a minor addition for some
extensibility it sounds like some will use.
[22:16] <mdiggory> PeterDietz: yes in that case I'm in agreement with putting
them there, but for the average non-developer, having a spot like this is good
to save them pain.
[22:16] <mdiggory> I want to caution, it is not an overlay of dspace-api.jar,
it is a separate jar
[22:16] <mdiggory> called api.jar
[22:17] <tdonohue> I think my main point here is that we just need to be clear
that code/files placed in [dspace]/modules/api/ does not end up in the same
place as code in [dspace-src]/dspace-api/ So, we should avoid that
misconception if possible.
[22:17] <mdiggory> you cannot overlay jars.
[22:17] <tdonohue> mdiggory -- exactly. that's why I worry the name "api" is
too close to "dspace-api"
[22:17] <PeterDietz> note: your overlay jar has to be alphabetically before
what it overrides
[22:17] <KevinVdV> What do you propose as a name then tdonohue ?
[22:17] <mhwood> local-api ?
[22:17] <sands> api doesn't rub me the wrong way. it seems relatively
consistent with other module naming schemes.
[22:18] <mhwood> aaa-local-api ?
[22:18] <mdiggory> the choice of "api" is also because of a benefit in
classpath ordering, you can copy and override dspace-api, jspui-api, xmlui-api
classes in that manner
[22:18] <tdonohue> ugh, I forgot about that whole alphabetic stuff.
[22:18] <hpottinger> mhwood: aaa-local-dspace-api
[22:19] <tdonohue> maybe "api" is the best we can do afterall. We can just be
clear about what it is and is not doing
[22:19] <PeterDietz> if our core stuff is all in dspace-api, then it logically
makes sense for the module overlay to be api
[22:19] <mdiggory> PeterDietz: its not an overlay :-P
[22:19] <tdonohue> PeterDietz -- the point there though is that what you said
isn't fully "true". [dspace]/module/api is NOT an overlay of dspace-api
[22:20] <PeterDietz> .rmpoint mdiggory
[22:20] <kompewter> PeterDietz: I'm sorry, but I'm afraid I can't do that!
[22:20] <tdonohue> instead, [dspace]/module/api/ is just a new "empty" module,
which lets you create your own custom API code that will be shared across all
Webapps (but won't end up in [dspace]/lib/)
[22:20] *** helix84 ([email protected]) joined
[22:20] <mdiggory> "Sorry Dave, I can't do that."
[22:21] <aschweer> "all-webapps"?
[22:21] <tdonohue> so, as mdiggory says, it's not a "true" overlay. It's
something different
[22:21] <KevinVdV> Second tdonohue it SHOULD end up in dspace/lib
[22:21] <aschweer> KevinVdV +1
[22:21] <KevinVdV> Because else your command line would use different code as
your webapp
[22:21] <tdonohue> but, it doesn't end up in [dspace]/lib/ right now (in these
patches)? Or did I misunderstand?
[22:22] <aschweer> KevinVdV ... which would get interesting if xmlui finds your
curation tasks but the command line doesn't
[22:22] <mdiggory> theres one more benefit to to the jar module, if it is a
dependency of all webapps and dspace/lib, you can just add new dependencies
for all projects in it as a single edit
[22:23] <mdiggory> dspace-additions
[22:23] <tdonohue> ok. so, maybe I'm wrong here. Does this "api.jar" end up
in [dspace]/lib as well as all Webapps? If so, then this all seems fine to me
and I'll just shut up now ;)
[22:24] <mdiggory> comes before dspace-api
[22:24] <KevinVdV> It WILL end up in the [dspace]/lib
[22:24] <mdiggory> then just call it dspace/modules/additions for directory name
[22:25] <tdonohue> ok. that wasn't clear to me. I withdraw my complaint then.
I'm fine if this is called "api"....we'll just be clear that it's creating a
new "api.jar" that is separate from the default "dspace-api.jar"
[22:25] <sands> +1
[22:25] <tdonohue> so, I'm +1 this addition as well
[22:26] <tdonohue> (just needs some corresponding documentation, obviously)
[22:26] <KevinVdV> Allrighty I'll prepare a new patch & contribute in the near
future
[22:26] <mhwood> We need to note somewhere that everything that comes with
DSpace must begin with "dspace-" (or, at least, something that sorts after
"additions").
[22:26] <mdiggory> tdonohue: the name or the contribution? mdiggory:
dspace-additions
[22:26] <tdonohue> mdiggory, I'm +1 the contribution.
[22:26] <PeterDietz> instead of a "patch", how about a pull request?
[22:27] <PeterDietz> you can add a link to the jira ticket
[22:27] <tdonohue> to me, the name "api" is OK. But, I'm not against changing
to "dspace-additions" (just don't feel strongly one way or the other, to be
honest)
[22:27] <KevinVdV> I'll see what I can cook up (still learning github)
[22:28] <mdiggory> I fear "api" is starting to feel like "core" thats why I'm
avoiding it.
[22:29] <mhwood> But it's not part of DSpace; it's part of your local
ScholarWorks or IDEALS or whatever.
[22:29] <tdonohue> mdiggory & mhwood : both are good points
[22:29] <mhwood> The part that comes with DSpace is just the hole you dorp it
into.
[22:29] <sands> not to beat this to death, but for the name, you could
technically be overriding (not overlaying now) a class in any module with this,
right? not just dspace-api?
[22:30] <tdonohue> "addon-api" (ugh), "api-local"
[22:30] <tdonohue> correct sands. You could be overlaying *any* module (as
long as this one is named in such a way that it's alphabetically first)
[22:30] <tdonohue> so, it's not just for overriding 'dspace-api'
[22:31] <KevinVdV> sands: well I wouldn't recommond overriding anything outside
of the dspace-api since it doesn't have any xmlui depencendencies for example
[22:31] <KevinVdV> You COULD add dependencies for xmlui stuff but then these
would end up in your [dspace]/lib directory which isn't good
[22:31] <sands> ok, well, i'd be fine with additions then, since it's more
accurate, less misleading, maybe more telling.
[22:31] <sands> KevinVdV: understood
[22:32] <mdiggory> sands: yes
[22:33] <mdiggory> not only any class in any module.... any class that comes
after "addons" on the classpath, even system classes
[22:33] <tdonohue> We're probably getting to the point of "thinking about this
too much". If anyone comes up with an amazing idea, add it to DS-981. The
name "additions" or "addons" is OK with me for now.
> Created a DSpace API module to contain api changes
> --------------------------------------------------
>
> Key: DS-981
> URL: https://jira.duraspace.org/browse/DS-981
> Project: DSpace
> Issue Type: New Feature
> Components: DSpace API, JSPUI, LNI, OAI-PMH, SWORD, XMLUI
> Reporter: Kevin Van de Velde
> Assignee: Kevin Van de Velde
> Priority: Major
> Attachments: api_module_patch.patch
>
>
> A new DSpace api module has been added, this makes it easier for the people
> who download a non source release of DSpace to put their api changes in a
> single place so that all the web apps may benefit from it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
