Re: [Discussion] Upgrading OFBiz to work with Java 11
I tried to run ofbiz with JDK 11, with following entry in build.gradle I am able to build and run ofbiz. runtime 'javax.xml.soap:javax.xml.soap-api:1.4.0' There are around 75 warnings (framework + plugins) Thanks & Regards -- Deepak Dixit On Wed, Dec 26, 2018 at 10:48 AM Girish Vasmatkar < girish.vasmat...@hotwaxsystems.com> wrote: > Hi Taher > > I haven't tried upgrading myself but I'm in for this effort. I think it > only makes sense to do the upgrade. I'll also try Java 11 and see how it > goes. > > Best, > Girish > > On Wed, Dec 26, 2018 at 1:25 AM Taher Alkhateeb < > slidingfilame...@gmail.com> > wrote: > > > Hi Folks, > > > > Now that we upgraded Gradle, I think we should consider moving to the > > new LTS (JDK 11)? I tried to upgrade to java 11 and got lots of > > issues. Some deprecated packages are removed and others changed > > signature. I got 2 errors and about 53 warnings for things that should > > be fixed. > > > > Should we go ahead and attempt the upgrade? Anyone already went > > through the effort and can help out? > > > > Taher Alkhateeb > > >
Re: Planning for the creation of new 18.12 branches
Yes, that would be a solution.
I'm also fine if we would do a 19.x branch. For the future, we could aim
to have a release more towards the middle of the year to avoid
last-minute branching between Christmas and New Year ;-)
The above would fit perfectly with this plan:
1. create an 18.12 branch and stabilize it
2. release 17.12 ;-)
3. create a 19.x (x = {6..10} branch with the Java Upgrade
This would not break the yearly release branch and give us time for the
Java 11 Update in 19.x. 19.x would be earlier next year so we get out of
the end of year-hurries .
Thanks,
Michael
Am 27.12.18 um 12:38 schrieb Taher Alkhateeb:
yeah I guess that would work too if it is okay to push a big change
into that branch
On Thu, Dec 27, 2018 at 1:44 PM Deepak Dixit wrote:
We can create a branch and can backport java upgrade changes to 18.12 as
well.
Thanks & Regards
--
Deepak Dixit
On Thu, Dec 27, 2018 at 3:21 PM Taher Alkhateeb
wrote:
It's okay whatever folks decide, but I think it would be nice if we
can upgrade Java for a new branch.
On Thu, Dec 27, 2018 at 12:05 PM Nicolas Malin
wrote:
Four days before the end of year :)
If no opposition, I will create it tomorrow
Nicolas
On 19/12/2018 11:44, Deepak Dixit wrote:
I agree,
We should create the next release (18.12) for framework and plugins.
I'll check for issues, and if found will share here.
Thanks & Regards
--
Deepak Dixit
On Wed, Dec 19, 2018 at 3:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Le 19/12/2018 à 10:14, Nicolas Malin a écrit :
Hello,
The time pass and the end year is near, maybe it's the time to
prepare
next releases branches.
Two questions :
* Are you agree to create releases 18.12 branches for framework and
plugin ?
* Do you have some priority issue that you absolutely need fbefore
create theses branches ?
I see for my point of view OFBIZ-4361 and OFBIZ-10145. I
believe/will/try to free some time for working on.
Cheers,
Nicolas
Hi Nicolas, All,
As I think we agreed, we need to check all the blocker before
releasing
(not freezing) .
So IMO OFBIZ-4361 and OFBIZ-10145 are not blocker for freezing a
possible
18.12 branches (trunk+plugins)
Thanks
Jacques
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Discussion] Upgrading OFBiz to work with Java 11
Hello, Taher Alkhateeb writes: > Now that we upgraded Gradle, I think we should consider moving to the > new LTS (JDK 11)? I tried to upgrade to java 11 and got lots of > issues. Some deprecated packages are removed and others changed > signature. I got 2 errors and about 53 warnings for things that should > be fixed. > > Should we go ahead and attempt the upgrade? Anyone already went > through the effort and can help out? I think the major challenge in that upgrade will be to handle the new module system which has been added in Java 9. For the record, OpenJDK 11 is still not available on the GNU/Linux distro I am using. So upgrading it right now would make my life harder. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Planning for the creation of new 18.12 branches
yeah I guess that would work too if it is okay to push a big change into that branch On Thu, Dec 27, 2018 at 1:44 PM Deepak Dixit wrote: > > We can create a branch and can backport java upgrade changes to 18.12 as > well. > Thanks & Regards > -- > Deepak Dixit > > > > On Thu, Dec 27, 2018 at 3:21 PM Taher Alkhateeb > wrote: > > > It's okay whatever folks decide, but I think it would be nice if we > > can upgrade Java for a new branch. > > > > On Thu, Dec 27, 2018 at 12:05 PM Nicolas Malin > > wrote: > > > > > > Four days before the end of year :) > > > > > > If no opposition, I will create it tomorrow > > > > > > Nicolas > > > > > > On 19/12/2018 11:44, Deepak Dixit wrote: > > > > I agree, > > > > > > > > We should create the next release (18.12) for framework and plugins. > > > > I'll check for issues, and if found will share here. > > > > Thanks & Regards > > > > -- > > > > Deepak Dixit > > > > > > > > > > > > > > > > On Wed, Dec 19, 2018 at 3:38 PM Jacques Le Roux < > > > > jacques.le.r...@les7arts.com> wrote: > > > > > > > >> Le 19/12/2018 à 10:14, Nicolas Malin a écrit : > > > >>> Hello, > > > >>> > > > >>> The time pass and the end year is near, maybe it's the time to > > prepare > > > >> next releases branches. > > > >>> Two questions : > > > >>> > > > >>> * Are you agree to create releases 18.12 branches for framework and > > > >> plugin ? > > > >>> * Do you have some priority issue that you absolutely need fbefore > > > >> create theses branches ? > > > >>> I see for my point of view OFBIZ-4361 and OFBIZ-10145. I > > > >> believe/will/try to free some time for working on. > > > >>> Cheers, > > > >>> > > > >>> Nicolas > > > >>> > > > >> Hi Nicolas, All, > > > >> > > > >> As I think we agreed, we need to check all the blocker before > > releasing > > > >> (not freezing) . > > > >> > > > >> So IMO OFBIZ-4361 and OFBIZ-10145 are not blocker for freezing a > > possible > > > >> 18.12 branches (trunk+plugins) > > > >> > > > >> Thanks > > > >> > > > >> Jacques > > > >> > > > >> > >
Re: Planning for the creation of new 18.12 branches
Yes I thought about that too, would not be a problem for me Jacques Le 27/12/2018 à 11:35, Deepak Dixit a écrit : We can create a branch and can backport java upgrade changes to 18.12 as well. Thanks & Regards -- Deepak Dixit On Thu, Dec 27, 2018 at 3:21 PM Taher Alkhateeb wrote: It's okay whatever folks decide, but I think it would be nice if we can upgrade Java for a new branch. On Thu, Dec 27, 2018 at 12:05 PM Nicolas Malin wrote: Four days before the end of year :) If no opposition, I will create it tomorrow Nicolas On 19/12/2018 11:44, Deepak Dixit wrote: I agree, We should create the next release (18.12) for framework and plugins. I'll check for issues, and if found will share here. Thanks & Regards -- Deepak Dixit On Wed, Dec 19, 2018 at 3:38 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 19/12/2018 à 10:14, Nicolas Malin a écrit : Hello, The time pass and the end year is near, maybe it's the time to prepare next releases branches. Two questions : * Are you agree to create releases 18.12 branches for framework and plugin ? * Do you have some priority issue that you absolutely need fbefore create theses branches ? I see for my point of view OFBIZ-4361 and OFBIZ-10145. I believe/will/try to free some time for working on. Cheers, Nicolas Hi Nicolas, All, As I think we agreed, we need to check all the blocker before releasing (not freezing) . So IMO OFBIZ-4361 and OFBIZ-10145 are not blocker for freezing a possible 18.12 branches (trunk+plugins) Thanks Jacques
Re: Planning for the creation of new 18.12 branches
We can create a branch and can backport java upgrade changes to 18.12 as well. Thanks & Regards -- Deepak Dixit On Thu, Dec 27, 2018 at 3:21 PM Taher Alkhateeb wrote: > It's okay whatever folks decide, but I think it would be nice if we > can upgrade Java for a new branch. > > On Thu, Dec 27, 2018 at 12:05 PM Nicolas Malin > wrote: > > > > Four days before the end of year :) > > > > If no opposition, I will create it tomorrow > > > > Nicolas > > > > On 19/12/2018 11:44, Deepak Dixit wrote: > > > I agree, > > > > > > We should create the next release (18.12) for framework and plugins. > > > I'll check for issues, and if found will share here. > > > Thanks & Regards > > > -- > > > Deepak Dixit > > > > > > > > > > > > On Wed, Dec 19, 2018 at 3:38 PM Jacques Le Roux < > > > jacques.le.r...@les7arts.com> wrote: > > > > > >> Le 19/12/2018 à 10:14, Nicolas Malin a écrit : > > >>> Hello, > > >>> > > >>> The time pass and the end year is near, maybe it's the time to > prepare > > >> next releases branches. > > >>> Two questions : > > >>> > > >>> * Are you agree to create releases 18.12 branches for framework and > > >> plugin ? > > >>> * Do you have some priority issue that you absolutely need fbefore > > >> create theses branches ? > > >>> I see for my point of view OFBIZ-4361 and OFBIZ-10145. I > > >> believe/will/try to free some time for working on. > > >>> Cheers, > > >>> > > >>> Nicolas > > >>> > > >> Hi Nicolas, All, > > >> > > >> As I think we agreed, we need to check all the blocker before > releasing > > >> (not freezing) . > > >> > > >> So IMO OFBIZ-4361 and OFBIZ-10145 are not blocker for freezing a > possible > > >> 18.12 branches (trunk+plugins) > > >> > > >> Thanks > > >> > > >> Jacques > > >> > > >> >
Re: Planning for the creation of new 18.12 branches
That's something that must be put in the balance indeed. No problems if we create a 19.01 or later branch for me... Jacques Le 27/12/2018 à 10:50, Taher Alkhateeb a écrit : It's okay whatever folks decide, but I think it would be nice if we can upgrade Java for a new branch. On Thu, Dec 27, 2018 at 12:05 PM Nicolas Malin wrote: Four days before the end of year :) If no opposition, I will create it tomorrow Nicolas On 19/12/2018 11:44, Deepak Dixit wrote: I agree, We should create the next release (18.12) for framework and plugins. I'll check for issues, and if found will share here. Thanks & Regards -- Deepak Dixit On Wed, Dec 19, 2018 at 3:38 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 19/12/2018 à 10:14, Nicolas Malin a écrit : Hello, The time pass and the end year is near, maybe it's the time to prepare next releases branches. Two questions : * Are you agree to create releases 18.12 branches for framework and plugin ? * Do you have some priority issue that you absolutely need fbefore create theses branches ? I see for my point of view OFBIZ-4361 and OFBIZ-10145. I believe/will/try to free some time for working on. Cheers, Nicolas Hi Nicolas, All, As I think we agreed, we need to check all the blocker before releasing (not freezing) . So IMO OFBIZ-4361 and OFBIZ-10145 are not blocker for freezing a possible 18.12 branches (trunk+plugins) Thanks Jacques
Re: [SUGGESTION] Common .derived file and AutoDeriv Eclipse plugin
Hi Girish,
Yes I'm aware of point 1 :)
Your point 2 is an interesting trick. With Autoderiv I can hide more than the build dir. Notably some dirs in runtime (not all of theml), w/o
limitation actually.
For instance, here is the content of my .derived file. I can add or remove as I
need.
.settings
bin
build
gradle
lib
runtime/indexes
runtime/catalina
runtime/data
runtime/logs/birt
runtime/output
runtime/tempfiles
runtime/tmp
runtime/uploads
FTW for the .class file it's more when opening than searching that I need to
hide.
For clean, it's used by cleanAll and I need that when I run the integration tests with:
"cleanAll eclipse loadAll testIntegration" (I do that often).
To be sure to have all things clean (devil is in the details, I got bitten more
than once by not cleaned data ;))
Thanks for sharing
Jacques
Le 27/12/2018 à 10:34, Girish Vasmatkar a écrit :
Hi Jacques
Following two settings help me not facing the issue you're facing. I, too,
ran into this issue when I initially set up OFBiz on eclipse.
1. Uncheck Show Derived Resources when you do CTRL+Shift+R, such that
only Show Status Line is checked. I am sure you have it correctly, but just
in case.
2. This does the trick mostly for me. By default, eclipse sets "bin"
directly as the output folder for the compiled files. I have it as
"build/classes". I think eclipse does not include resources present in the
output folder as part of search result, so setting the default output
folder as gradle's output folder i.e. *build/classes* does the trick for
me. I am unsure if that's what you're looking for.
So even if the derived setting is gone after clean task is run, if the
output folder is set to *build/classes*, your search results should not
include .class files.
Also, when I am using eclipse for the development, almost always I rely on
eclipse for compiling the sources. I have not used gradle clean task for a
while. But with the about setting (changing default output folder), gradle
clean task does not affect my search results i.e. it does not include
.class files.
Based on what I understood, I think above should help. Please let me know
if that's not the case.
Best,
Girish
On Wed, Dec 26, 2018 at 9:06 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi Michael,
I asked because so far when you updated Eclipse you were losing your
plugins and their configurations. I recently updated to Photon and it's no
longer
the case. So it's no longer an issue for me :). At least as long as the
repos locations don't change. I'd then lose my local .derived file and
would
surely I'd forget about it :/. But this should not happen before a long
time...
About the .class files showing when using Ctrl+Shift+R (opening a
ressource). It's not a configuration problem on my side.
I guess when you speak about filters you think about what is explained in
the second answer of
https://stackoverflow.com/questions/443169/exclude-folders-from-eclipse-search
.
As you can see in comments there both options (derived and filters) have
advantages and drawbacks. I personally prefer using derived ("the *quick*
and
dirty way", very handy). But, as explained in stackoverflow, you face an
Eclipse bug. That's why AutoDeriv exists.
So what's the problem for me? When you use the clean task, Gradle removes
the build dir. So also the dir where the .class files are (build\classes).
And then you lose the derived properties for these dirs :/
Since to hide these files from opening or searching you need to set them
as derived, each time you use clean (I do it a lot) you loose this config.
That's why I use, and suggest to use as in wiki, the AutoDeriv plugin.
Anyway as I said it's no longer a trivial but irritating concern for me
and I don't want to shoehorn anybody with my solutions :)
Thanks for answering
Happy holidays
Jacques
Le 18/12/2018 à 07:44, Michael Brohl a écrit :
Hi Jacques,
who is going to decide which files you want to see and which you don't
want so see? People have different taste on that and so you would be
struggling with different settings checked in to the code repository.
I'm not in favor of putting these files into the repository. I think
these are specific for each developer and it's no problem to keep them
locally.
For your specific examples: I don't see any .class files when searching,
that must be a configuration problem on your side. For searching, you can
also set up filters which provide an efficient mechanism to search (or
don't search) specific files.
Thanks,
Michael
Am 17.12.18 um 14:11 schrieb Jacques Le Roux:
Hi,
I know we don't all use Eclipse but I though want to make a suggestion.
2 years ago I put this tip at
https://cwiki.apache.org/confluence/display/OFBIZ/Eclipse+Tips#EclipseTips-Hidefoldersfromsearches
:
<
opening a file.
Most of the time you don't want to look into some folders because
there is nothing interesting there and they sometimes
Re: Planning for the creation of new 18.12 branches
It's okay whatever folks decide, but I think it would be nice if we can upgrade Java for a new branch. On Thu, Dec 27, 2018 at 12:05 PM Nicolas Malin wrote: > > Four days before the end of year :) > > If no opposition, I will create it tomorrow > > Nicolas > > On 19/12/2018 11:44, Deepak Dixit wrote: > > I agree, > > > > We should create the next release (18.12) for framework and plugins. > > I'll check for issues, and if found will share here. > > Thanks & Regards > > -- > > Deepak Dixit > > > > > > > > On Wed, Dec 19, 2018 at 3:38 PM Jacques Le Roux < > > jacques.le.r...@les7arts.com> wrote: > > > >> Le 19/12/2018 à 10:14, Nicolas Malin a écrit : > >>> Hello, > >>> > >>> The time pass and the end year is near, maybe it's the time to prepare > >> next releases branches. > >>> Two questions : > >>> > >>> * Are you agree to create releases 18.12 branches for framework and > >> plugin ? > >>> * Do you have some priority issue that you absolutely need fbefore > >> create theses branches ? > >>> I see for my point of view OFBIZ-4361 and OFBIZ-10145. I > >> believe/will/try to free some time for working on. > >>> Cheers, > >>> > >>> Nicolas > >>> > >> Hi Nicolas, All, > >> > >> As I think we agreed, we need to check all the blocker before releasing > >> (not freezing) . > >> > >> So IMO OFBIZ-4361 and OFBIZ-10145 are not blocker for freezing a possible > >> 18.12 branches (trunk+plugins) > >> > >> Thanks > >> > >> Jacques > >> > >>
Re: [SUGGESTION] Common .derived file and AutoDeriv Eclipse plugin
Hi Jacques
Following two settings help me not facing the issue you're facing. I, too,
ran into this issue when I initially set up OFBiz on eclipse.
1. Uncheck Show Derived Resources when you do CTRL+Shift+R, such that
only Show Status Line is checked. I am sure you have it correctly, but just
in case.
2. This does the trick mostly for me. By default, eclipse sets "bin"
directly as the output folder for the compiled files. I have it as
"build/classes". I think eclipse does not include resources present in the
output folder as part of search result, so setting the default output
folder as gradle's output folder i.e. *build/classes* does the trick for
me. I am unsure if that's what you're looking for.
So even if the derived setting is gone after clean task is run, if the
output folder is set to *build/classes*, your search results should not
include .class files.
Also, when I am using eclipse for the development, almost always I rely on
eclipse for compiling the sources. I have not used gradle clean task for a
while. But with the about setting (changing default output folder), gradle
clean task does not affect my search results i.e. it does not include
.class files.
Based on what I understood, I think above should help. Please let me know
if that's not the case.
Best,
Girish
On Wed, Dec 26, 2018 at 9:06 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> Hi Michael,
>
> I asked because so far when you updated Eclipse you were losing your
> plugins and their configurations. I recently updated to Photon and it's no
> longer
> the case. So it's no longer an issue for me :). At least as long as the
> repos locations don't change. I'd then lose my local .derived file and
> would
> surely I'd forget about it :/. But this should not happen before a long
> time...
>
> About the .class files showing when using Ctrl+Shift+R (opening a
> ressource). It's not a configuration problem on my side.
>
> I guess when you speak about filters you think about what is explained in
> the second answer of
>
> https://stackoverflow.com/questions/443169/exclude-folders-from-eclipse-search
> .
>
> As you can see in comments there both options (derived and filters) have
> advantages and drawbacks. I personally prefer using derived ("the *quick*
> and
> dirty way", very handy). But, as explained in stackoverflow, you face an
> Eclipse bug. That's why AutoDeriv exists.
>
> So what's the problem for me? When you use the clean task, Gradle removes
> the build dir. So also the dir where the .class files are (build\classes).
> And then you lose the derived properties for these dirs :/
>
> Since to hide these files from opening or searching you need to set them
> as derived, each time you use clean (I do it a lot) you loose this config.
> That's why I use, and suggest to use as in wiki, the AutoDeriv plugin.
>
> Anyway as I said it's no longer a trivial but irritating concern for me
> and I don't want to shoehorn anybody with my solutions :)
>
> Thanks for answering
>
> Happy holidays
>
> Jacques
>
> Le 18/12/2018 à 07:44, Michael Brohl a écrit :
> > Hi Jacques,
> >
> > who is going to decide which files you want to see and which you don't
> want so see? People have different taste on that and so you would be
> > struggling with different settings checked in to the code repository.
> >
> > I'm not in favor of putting these files into the repository. I think
> these are specific for each developer and it's no problem to keep them
> locally.
> >
> > For your specific examples: I don't see any .class files when searching,
> that must be a configuration problem on your side. For searching, you can
> > also set up filters which provide an efficient mechanism to search (or
> don't search) specific files.
> >
> > Thanks,
> >
> > Michael
> >
> >
> > Am 17.12.18 um 14:11 schrieb Jacques Le Roux:
> >> Hi,
> >>
> >> I know we don't all use Eclipse but I though want to make a suggestion.
> >>
> >> 2 years ago I put this tip at
> https://cwiki.apache.org/confluence/display/OFBIZ/Eclipse+Tips#EclipseTips-Hidefoldersfromsearches
> :
> >>
> >>
> >>< opening a file.
> >>
> >>Most of the time you don't want to look into some folders because
> there is nothing interesting there and they sometimes annoy you because of
> >>search errors (triste)
> >>It's also annoying to see *.class files when you look for a
> similarly named Java source.
> >>Then you tool of choice is https://nodj.github.io/AutoDeriv/>>
> >>
Re: Planning for the creation of new 18.12 branches
Four days before the end of year :) If no opposition, I will create it tomorrow Nicolas On 19/12/2018 11:44, Deepak Dixit wrote: I agree, We should create the next release (18.12) for framework and plugins. I'll check for issues, and if found will share here. Thanks & Regards -- Deepak Dixit On Wed, Dec 19, 2018 at 3:38 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 19/12/2018 à 10:14, Nicolas Malin a écrit : Hello, The time pass and the end year is near, maybe it's the time to prepare next releases branches. Two questions : * Are you agree to create releases 18.12 branches for framework and plugin ? * Do you have some priority issue that you absolutely need fbefore create theses branches ? I see for my point of view OFBIZ-4361 and OFBIZ-10145. I believe/will/try to free some time for working on. Cheers, Nicolas Hi Nicolas, All, As I think we agreed, we need to check all the blocker before releasing (not freezing) . So IMO OFBIZ-4361 and OFBIZ-10145 are not blocker for freezing a possible 18.12 branches (trunk+plugins) Thanks Jacques
