I think option 2 is just fine. In fact it would be fine for nearly
all plugins. We could do it for all version control plugins to be
consistent. Then we wont get complaints from svn users that
subversion is a second class citizen and the default
install/footprint gets smaller again..
manfred
On 12-02-03 08:22 AM, Winston Prakash wrote:
There are two options
- Bundle subversion plugin in the war and install SVNKit
dynamically on the first run.
- Don't bundle the subversion plugin in the war (keep the source
at Github and release it from there). Give an opportunity to the
user to install it at first run along with few others such as
JFreechart or JNA if needed.
Option 1 is complicated.
- Plugin manager extracts the plugin from war and creates the
folder <HUDSON-HOME>/plugins/subversion, when hudson first
starts.
- We need to install svnkit under
<HUDSON-HOME>/plugins/subversion/WEB-INF/lib
- But when Plugin manager extract the plugin, it also loads the
plugin and thus would break hudson
- Also since we build subversion plugin with out svnkit, if there
is a upgrade, that would also break. Because the plugin folder is
wiped out first along with svnkit.
IMO, the easiest option is option 2.
- Winston
On 2/3/12 12:56 AM, Duncan Mills wrote:
Folks
In relation to the CQ request for SVNKit 1.3.7 (CQ
6184). We have hit a bit of a roadblock in that we can't
distribute SVNKit from Eclipse.org (see extract below)
Given that SVN is very much part of Hudson Core I don't think
that we want to push it out onto the Plug-ins site (although
that's an option in the short term). How feasible is the
self-bootstrapping idea where we pull the JAR dynamically on
first run?
Duncan
<extract>
------- Comment #5 From Wayne Beaton 2012-02-02 12:05:55
[reply] -------
IP review of previous versions of SVNKit have determined that
there are "difficulties associated with licensing and
pedigree".
The TMate license has been determined to be incompatible with
the EPL; this is--essentially--a full stop with respect to any
effort to distribute this library from Eclipse.
There is potential to have this library declared as a
"WORKSWITH" on the basis that Hudson works just fine without
this library, but has enhanced functionality if the library is
present. The wrinkle is that the library cannot be distributed
from eclipse.org (i.e. it cannot exist in our code
repositories, or download server). It may be used to compile
as part of a build on our build server as the build server is
not accessible to the general public.
FWIW, the Subversive project uses SVNKit in this manner. The
first time you use Subversive, they open a dialog box that
invites the user to download SVNKit (among other options); at
that point the user is required to accept the license
explicitly.
Do you want to move forward with this as a WORKSWITH? Let me
know if you have other questions.
</extract>
--
Regards,
Duncan
Duncan Mills | Senior Director
Phone: +44 (0)7824 626354
Oracle Application
Development Tools
United Kingdom
ORACLE Corporation
UK Ltd is a company incorporated in England & Wales |
Company Reg. No. 1782505 | Reg. office: Oracle Parkway,
Thames Valley Park, Reading RG6 1RA
 Oracle
is committed to developing practices and products that
help protect the environment
_______________________________________________
hudson-dev mailing list
hudson-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hudson-dev
_______________________________________________
hudson-dev mailing list
hudson-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hudson-dev
--
Manfred Moser
http://simpligility.com
|
