Hi Jacques,
Perhaps I did not emphasize this point so I'll try to make it clear:
JitPack does not work! It creates jars from github projects which are not
published. Therefore it does not fit as a complement to plugins which are
just OFBiz components.
If you want to use the latest version of a plugin or you don't want to
publish it to a maven repo, then just clone the repository into
/specialpurpose and run the install task and you're done.
So we will only need this plugin if we have libraries (jars not plugins)
that we need in OFBiz that exist in github and are not published in any
maven repo (like jcenter or mavencentral, etc...)
Taher Alkhateeb
On Sep 9, 2016 8:36 AM, "Jacques Le Roux" <jacques.le.r...@les7arts.com>
wrote:
> Taher, inline...
>
> Le 09/09/2016 à 05:40, Taher Alkhateeb a écrit :
>
>> Hi Jacques,
>>
>> JitPack is indeed a nice service and plugin. However I think it might not
>> be a good fit for the plugin system because:
>>
>> - You're mixing up jar dependencies with components. OFBiz components are
>> not jars and do not require pre-compilation. The primary purpose of
>> JitPack
>> is to build jars on demand if they are not available on public repos.
>>
>
> Yes that's my point, we would have something dynamic, could be a good
> complement when working together on a plugin, together could be only the
> plugin provider and the plugin user
> It's easier for the plugin provider to fix an issue and faster for the
> plugin user to get the stuff up to date. Because you don't have to upload
> to a Maven repo. We could even use the -SNAPSHOT feature. Of course this is
> only intended for the development phase, but why not?
>
> - it requires rewriting all components to allow publishing.
>>
>
> We could use it only as a complement
>
> - it depends on a single vendor (vendor lock in)
>>
>
> It's not a vendor, it's freely available, so are a lot of things we use.
> If it disappears, then the feature will disappear with it, not preventing
> us to continue to use the main way.
>
> - it requires service registration to use.
>>
>
> Not at all, I did not register, simply used the patch I send in a message
> in the other thread
>
> - it does not provide dependency management
>>
>
> Right, it should be used with care, like you use a replacement wheel
>
> - it is less flexible. Maven packages can contain anything and can be
>> hosted everywhere (localhost, jcenter, maven central, private maven, etc).
>>
>
> It's only a complement not a replacement
>
> So not only is it not compatible with OFBiz components but also more
>> complex to use as described above.
>>
>
> It's very easy to use, here is the patch again, nothing else needed and
> does not prevent anything
>
> Index: build.gradle
> ===================================================================
> --- build.gradle (revision 1759557)
> +++ build.gradle (working copy)
> @@ -30,12 +30,6 @@
> // operating system property
> ext.os = System.getProperty('os.name').toLowerCase()
>
> -// java settings
> -def jvmArguments = ['-Xms128M', '-Xmx1024M',
> - "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria
> l-1.0-SNAPSHOT.jar",
> - "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri
> al/empty.txt",
> - "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/
> is-deserialized.txt",
> - "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/
> deserialize-trace.txt"]
> ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start'
> javadoc.failOnError = false
> sourceCompatibility = '1.8'
> @@ -52,6 +46,7 @@
> allprojects {
> repositories{
> jcenter()
> + maven { url "https://jitpack.io"; }
> }
> }
>
> @@ -119,6 +114,7 @@
> compile 'org.zapodot:jackson-databind-java-optional:2.4.2'
> compile 'oro:oro:2.0.8'
> compile 'wsdl4j:wsdl4j:1.6.2'
> + compile 'com.github.kantega:notsoserial:f2baaaa'
>
> // general framework runtime libs
> runtime 'de.odysseus.juel:juel-spi:2.2.7'
> @@ -176,6 +172,16 @@
> runtime files("${rootDir}/build/libs/ofbiz-base-test.jar")
> }
>
> +// Java settings, must be after the dependencies block to avoid a:
> org.gradle.api.InvalidUserDataException:
> +// Cannot change dependencies of configuration ':compile' after it has
> been resolved.
> +def notsoerialFileNameWithPath = project.configurations.compile.find {
> it.name.startsWith("notsoserial-") }
> +def jvmArguments = ['-Xms128M', '-Xmx1024M',
> + "-javaagent:" + notsoerialFileNameWithPath,
> + "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri
> al/empty.txt",
> + "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/
> is-deserialized.txt",
> + "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/
> deserialize-trace.txt"]
> +
> +
> def excludedJavaSources = []
> excludedJavaSources.add 'org/apache/ofbiz/accounting/t
> hirdparty/cybersource/IcsPaymentServices.java'
> excludedJavaSources.add 'org/apache/ofbiz/accounting/t
> hirdparty/ideal/IdealEvents.java'
>
> Jacques
>
>
>
>> Taher Alkhateeb
>>
>> On Sep 9, 2016 12:31 AM, "Jacques Le Roux" <jacques.le.r...@les7arts.com>
>> wrote:
>>
>> Hi Taher,
>>>
>>> While working on notsoserial, I got an idea about using JitPack in
>>> conjunction with GitHub for OFBiz-Gradle plugins.
>>> JitPack has a MIT license and allows to freely use standard GitHub
>>> repositories (like https://github.com/apache/ofbiz)*.
>>> *
>>>
>>> When you use JitPackyou don't download jars but build jars in your Gradle
>>> cache from the sources on GitHub.
>>>
>>> For instance it was very easy for me to directly compile notsoserial (
>>> https://github.com/kantega/notsoserial they have a pom.xml there) and
>>> have the jar put in my Gradle cache.
>>>
>>> JitPack allows also to use private (but not free) repositories
>>> https://jitpack.io/private. This could maybe make sense to provide paid
>>> plugins. But because only a credential is needed to gain access, it's
>>> maybe
>>> not enough, you would have to create a paid repo by client.
>>>
>>> The FAQ is here https://github.com/jitpack/jitpack.io/blob/master/FAQ.md
>>>
>>> So it would be easier for us (OFBiz team) and contributors to deliver (at
>>> least free) plugins w/o having to publish then in a Maven or "Gradle"
>>> (jcenter) repository.
>>> A simple project in GitHub, done! When you know how GitHub changed the
>>> open source world it's IMO interesting, simple and efficient.
>>>
>>> Jacques
>>>
>>> Le 28/08/2016 à 18:41, Taher Alkhateeb a écrit :
>>>
>>> Hi Everyone,
>>>>
>>>> I am very happy to announce that after a lot of research I finally have
>>>> a
>>>> little working PoC solution for the OFBiz plugin system. I believe this
>>>> system is very simple yet very powerful with the following simple API
>>>> tasks
>>>>
>>>> 1- ./gradlew createPlugin: creates a plugin from templates
>>>> 2- ./gradlew installPlugin: downloads a plugin and all its dependency
>>>> plugins from a maven repository(it could be local, remote, jcenter,
>>>> whatever), extracts the archives, add the plugin to component-load.xml,
>>>> and
>>>> calls the install task.
>>>> 3- ./gradlew uninstallPlugin: calls the uninstall task, removes the
>>>> plugin
>>>> from component-load.xml, and deletes the plugin (but ignores
>>>> dependencies).
>>>> 4- ./gradlew publishPlugin: create a maven compatible package that can
>>>> be
>>>> published to either a local or a remote repository.
>>>>
>>>> So what is very powerful about this solution? Well, you use the maven
>>>> format for your packages, so you can host it on any maven repository
>>>> including jcenter. Also, you have a standard way of declaring
>>>> dependencies
>>>> (pom.xml) and you pretty much gain all the benefits that comes with
>>>> maven
>>>> packages (versioning, dependencies, meta data, etc ...)
>>>>
>>>> The solution can be expanded later on, but I think the above provides a
>>>> good starting point. Ideas? Feedback? Should I go ahead and fine-tune /
>>>> share the PoC on JIRA?
>>>>
>>>> Regards,
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux <
>>>> jacques.le.r...@les7arts.com> wrote:
>>>>
>>>> Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :
>>>>
>>>>> Hello Everyone,
>>>>>
>>>>>> I need some opinions for a PoC that I'm working on for the plugin
>>>>>> system
>>>>>> (OFBIZ-7972) and appreciate your help:
>>>>>>
>>>>>> repository design
>>>>>> ----------------------
>>>>>> I am thinking of just having a very simple web server denoted as a
>>>>>> repository where the plugins are just zip or tar archives that expand
>>>>>> to
>>>>>> OFBiz components. For example, if the repository URL is
>>>>>> www.example.com
>>>>>> then the plugin could be www.example.com/plugins/Specif
>>>>>> icPluginHere.tar.gz.
>>>>>> It downloads to the specialpurpose (hopefully renamed to plugins) to
>>>>>> expand
>>>>>> and install
>>>>>>
>>>>>> I'm for removing the difference between specialpurpose and hot-deploy.
>>>>>>
>>>>> Why? Simplification!
>>>>>
>>>>> We should remove specialpurpose and rename hot-deploy into plugins.
>>>>> This also means that we should have a Gradle task to automatically
>>>>> download and install a plugin.
>>>>> All current specialpurpose would become plugins available in the repo
>>>>> easily installable using something like
>>>>> gradlew installPlugins plugins1Name plugins2Name etc.
>>>>> I don't see the need to have a differentiated task to install only 1
>>>>> plugin
>>>>>
>>>>> The repo should be installed on the new OFBIZ-VM2
>>>>>
>>>>> We know that, like for the misnamed hot-deploy, installing a plugin
>>>>> will
>>>>> need a restart of the OFBiz instance.
>>>>> So this can't be dynamically done (at least for now), but need to be at
>>>>> least automated.
>>>>>
>>>>> The only current issue is if we have dependencies among plugins.
>>>>> For now we can simply documented them for users to set their own
>>>>> component-load.xml
>>>>>
>>>>> BTW as a reminder, after OFBIZ-6760 we need to update
>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Component+
>>>>> and+Component+Set+Dependencies
>>>>> And possibly complete the possible existing interdependencies between
>>>>> specialpurpose components, though I can't remember any, but I feel I'm
>>>>> wrong here.
>>>>>
>>>>>
>>>>> dependencies
>>>>>
>>>>> ------------------
>>>>>> This is a complicated subject, and there are a few ideas I have in
>>>>>> mind:
>>>>>> - Try to deploy the gradle project dependency model
>>>>>>
>>>>>> I'd like to know if you crossed issues with that and if yes what they
>>>>>>
>>>>> are.
>>>>> If it's the case can't we share the burden?
>>>>>
>>>>> - Alternatively write custom dependency resolution
>>>>> Please no :)
>>>>>
>>>>> However, this might be too complex to kickstart the project, and I
>>>>> think
>>>>>
>>>>> perhaps we can start without a dependency management system and
>>>>>> implement
>>>>>> it in a later stage.
>>>>>>
>>>>>> Yes why not? Baby steps for the win
>>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Thank you in advance for your help and feedback.
>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>
