On 08/11/2011 03:57 PM, Marlon Pierce wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Considering the case at hand, I need to extend DefaultUserService.java
(and UserService.java), which are in
rave-portal/src/main/java/org/apache/rave/portal/service/.
So, you'll at least need these in your classpath to be able to extend and build,
right?
Using a war overlay like we do with rave-shindig then won't help you: a maven
dependency on a war artifact won't expose its classpath.
This is why I think you'll need a proper separated module to do this.
Other than that and I think also mentioned some time before, I'd prefer
minimizing usage of war overlays, actually eventually even get rid of the
rave-shindig war overlay. They are just too cumbersome to work with, an easy
cause of "duplicate jar" hell, and have little or no support at all within IDEs.
These will
have a dependency on the UserRepository, so this will need to be wired
up. Other services (including unwritten ones) could also depend on the
UserRepository. This could be avoided by just extending the UserService
interface, but for my case this is not ideal--I only need to override
one method in DefaultUserService.
So we may not have enough use cases yet to decide on the optimal
reorganization of the code.
I'm happy to try Matt's recommended Spring magic in the short term.
Marlon
On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
-----Original Message----- From: Ate Douma [mailto:[email protected]]
Sent: Thursday, August 11, 2011 8:38 AM To:
[email protected] Subject: [DISCUSS] (RAVE-171) The
maven install for rave-portal should create a jar as well as a war
and deploy this jar to the local repository.
IMO this is not the way how we should solve extensibility of the
functionality currently within the rave-portal module.
+1
Producing multiple artifacts from a single Maven module (pom) is a
bad pattern in general, as additional artifacts won't have any
meta-data context attached. For example, this additional
rave-portal jar artifact from the rave-portal war pom won't have
any transitive dependencies meta-data, nor will you have (from
maven) any "reference" back to its source origin, etc.
I think that if we want to be able to make the functionality within
rave-portal extendable/customizable, we better start factoring
these out into real "component" or "service" modules. And add and
isolate interfaces and APIs so they can become "pluggable" by
themselves. The rave-commons module already represents one type of
such modularization, but I think we'll need to go much further.
Possibly, but I think there might be a simpler way to handle it for
now.
My proposal would be to create a new rave pom module called
something like "rave-components" or "rave-services" and a) move
rave-commons under it as a sub module b) initiate a new sub module
(rave-security?) isolating the functionality currently within
rave-portal to be extended upon like by the science-gateway in the
sandbox
I would recommend having the science gateway use an overlay like we
do with rave-shindig. This way, you can override implementations in
rave-portal by injecting beans marked primary in the Spring
application context. This shouldn't be too difficult to setup.
WDYT?
Regards,
Ate
On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
The maven install for rave-portal should create a jar as well as
a war and
deploy this jar to the local repository.
---------------------------------------------------------------------------------------------
- -----------------------
Key: RAVE-171 URL:
https://issues.apache.org/jira/browse/RAVE-171 Project: Rave
Issue Type: Sub-task Reporter: Marlon Pierce
Extension codes not in rave-portal src tree will need to be able
to compile
against that code. This can be done by modifying
rave-portal/pom.xml so that it makes both a war and a jar and
installs both in the local repository. The extension code should
then have the appropriate dependency in its pom.xml
-- This message is automatically generated by JIRA. For more
information on JIRA, see: http://www.atlassian.com/software/jira
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOQ9/mAAoJEEfVXEODPFIDVqwH/0zOWIxXQfKP4avJS+qmNQjL
rfurBDxCXWbCJrS0n4JL3oXoY6w8LQlXqtgXHTeVBSrLjFDAPIrzMk/NxDKM0DvZ
yQA+FVi4FbU4W8rTaVDaG61T8zoNVTkQ04HRIAr4Zoa253U54RRZm4//99LH/LfW
BPq6M2hIItziVORzbrhOPJXp8006rLpyrLJq0r7ora42VlH4dtIi3pIouclPrYau
iRBQ2QLeZ/MSIwzH4+apMmVswXzfKDuCwVWX0/M6mq69MWCmVdvr8W1ucAceYJ+9
RbiuvQzTK/THCiUmFt4/wtWUB21kqoJwfqnuOl/hNhDcPg/B13LqSXCt1rxQcm0=
=9fhF
-----END PGP SIGNATURE-----
