Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] [External] : No org.eclipse.persistence.asm for Eclipselink 2.7.9? 
On 7/26/21 11:44 PM, William Dazey wrote:

Ok, I see now that the "EclipseLink ASM source" I was referring to is
all checked into master. I understand now it is built as needed from
master. I think it USED to be in each individual release branch, but
was moved to master to consolidate it.
It was deleted from 2.x as it became irrelevant there and it does not make sense to keep maintaining multiple copies of the same stuff 



I am investigating migrating it out to a new repository. I think
having that code all live in master is essentially the same process,
but not as obvious or official.
there is no official guidance wrt to this. There are projects having multiple more or less or even fully independent pieces within one repo as well as those having a repo for every single unit. 


 I think having it live in it's own

repository is much cleaner and official. Thoughts?


each approach has its own advantages and disadvantages.

There are basically 2 options we have:

1) have a new standalone repo for eclipselink-asm

advantages:
  * the purpose of the repo is clear
  * no conflicts in tags, branches etc
disadvantages:
  * another repository to maintain
* another set of required legal files to maintain (and update all existing ones in current repos) * the repo needs to be created by Eclipse Foundation guys; basically a bug needs to be filed in bugzilla under appropriate Community subcomponent and this may take some time * not so easy to test changes in ASM on CI within the context of full eclipselink 

2) keep both projects in one repo

advantages:
  * no additional repo to maintain
  * no 3rd person (even when it is one-time action) involvement required
  * easy to make asm project part of full build for testing purposes
disadvantages:
  * source of the project is not immediately visible
  * tags/branches may become confusing to first commers
  * git tags/branches whole repo, not just particular folder like ie SVN
whether option 1 or 2 gets chosen, one use-case which should be kept in mind is how to allow automatic testing of changes in ASM within context of full eclipselink - in the other words on the SNAPSHOT build of the o.e.p.asm bundle.
with option 1, the testing job needs to be set up to grab sources from two repositories, build the asm one first, "auto-update" asm.version property in eclipselink source tree to the snapshot version built in previous step and run the build/tests; with option 2 there is just one repo, so the checkout step is easier. Having said that, I'm not sure option 1 can be implemented through GH actions, while there should be no issue in using GH actions with option 2.
Since I already work on few dozens GH repos, less is more for me, but I understand that for others it may be more convenient to have more repositories. 

thanks,
--lukas



Thanks,
Will Dazey

On Mon, Jul 26, 2021 at 4:31 PM Lukas Jungmann
<lukas.jungmann@xxxxxxxxxx> wrote:


On 7/26/21 11:06 PM, William Dazey wrote:

To be clear, I am not referring to the ASM source. From my
understanding, the build process pulls in the base ASM source from the
ASM project (or maybe maven) so that we can repackage it with
`org.eclipse.persistence.asm.*`. For instance,
https://urldefense.com/v3/__https://asm.ow2.io/javadoc/org/objectweb/asm/ClassWriter.html__;!!ACWV5N9M2RV99hQ!bmjB3firWfdbMtPoVoyHE5hnAlHfhq712cvomfMP4Nvnn6TJFehFb5skdUySJerACFY$  is
pulled in, repackaged into
`org.eclipse.persistence.internal.libraries.asm.ClassWriter`.

I'm talking about the source that builds
`org.eclipse.persistence:org.eclipse.persistence.asm:9.1.0`. How does
`org.eclipse.persistence.internal.libraries.asm.EclipseLinkASMClassWriter`
get created? Where does that code exist?


I open https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink__;!!ACWV5N9M2RV99hQ!cU8Y8-G0Z_Yddte9BkjjbP9yDF17HMxGuDglUar2JvOQCzIfZVnxEDGfRXlzzdNLNbU$
I click on the "Go to file" button
I type in "EclipseLinkASMClassWriter"

=> I see the link to the source

thanks,
--lukas




Thanks,
Will Dazey

On Mon, Jul 26, 2021 at 3:30 PM William Dazey <dazeydev.3@xxxxxxxxx> wrote:



That would be possible if the sources were in 2.7 branch. But that is NOT the case. It is also no longer part of 2.7 (or 3.x if you want) release build


Ok, so where does the source exist now? We built
org.eclipse.persistence:org.eclipse.persistence.asm:9.1.0 and uploaded
to maven central, yes? How did that bundle get built? From which
release branch?

I am assuming what you mean is that maybe there is no EclipseLink ASM
source code and that what we do is pull in ASM source, make changes at
build time, repackage it as an EclipseLink ASM bundle
(org.eclipse.persistence:org.eclipse.persistence.asm) and then publish
it? So where does THAT build process get run? Is that code checked
into any release branches?

Thanks,
Will Dazey

On Mon, Jul 26, 2021 at 3:00 PM Lukas Jungmann
<lukas.jungmann@xxxxxxxxxx> wrote:




26. 7. 2021 v 20:10, William Dazey <dazeydev.3@xxxxxxxxx>:

Hello!

Do you think it would be better to keep publishing the same binary under 2, 3, 4+ different version numbers - one for 2.6 stream, one for 2.7, another for 3.0 and in foreseeable also one for 3.1, generally, going forward, one for each maintained version stream - in maven central instead of having just one binary there and letting all streams to depend on that one?


Correct me if I'm wrong please. Each release branch (2.6, 2.7, 3.0,
master) has their own ASM code checked into it, yes?


I do not see it at https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink/tree/2.7/plugins__;!!ACWV5N9M2RV99hQ!bmjB3firWfdbMtPoVoyHE5hnAlHfhq712cvomfMP4Nvnn6TJFehFb5skdUySfYfhdxw$  where it used to be. Do you see it on some other place? 2.6 may still have it as I’m not sure that branch was updated already

However, we
assume they are all at the same exact code then only build one, assign
it the official ASM version in maven central (for instance
`org.eclipse.persistence:org.eclipse.persistence.asm:9.1.0`), and let
all EclipseLink releases share in that build?


Yes. We only don’t assume, we KNOW it is all the same code. Just take a look at package versions being exported from those different versions of the same jar - one can easily find matching pairs in 2.6 and 2.7 versions, so from OSGi point of view, there is ie almost no difference between what maven sees as 2.7.7 and 2.6.8. The only difference is the qualifier part of the Bundle-Version header, so really no semantic difference


So, for instance, we can build the EclipseLink ASM code in the 2.7
release branch, upload to maven central calling it
`org.eclipse.persistence:org.eclipse.persistence.asm:9.1.0`, AND use
it for the 3.0.2 release as well! Even though the 3.0 release branch
has its own EclipseLink ASM code checked into that git branch...


That would be possible if the sources were in 2.7 branch. But that is NOT the case. It is also no longer part of 2.7 (or 3.x if you want) release build, so the only case when this could happen is explicit intention. In theory, this can happen in 3.x streams but again - it would have to be done with explicit intent.

BTW: what’s in maven central already is written in a stone and cannot be changed. There is no way to overwrite or remove artifacts from there. Only rare exceptions from this rule are made by sonatype


I think it is great to have ONE EclipseLink ASM release
(`org.eclipse.persistence:org.eclipse.persistence.asm:9.0.0` or
`org.eclipse.persistence:org.eclipse.persistence.asm:9.1.0`) since
there should not be really any differences between EclipseLink
releases (2.6, 2.7, 3.0, master) that warrant needing separate builds.
HOWEVER, I also think it then makes no sense for that ASM code to be
checked into those individual branches. Instead, EclipseLink ASM
should be pull out into its own repository (for instance,
https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink-asm__;!!ACWV5N9M2RV99hQ!YiPSFL1bj2w4dTEV8gt3OLrTCUWLFpg0rARQArj0Kvmt9MYYAf1HGvB8sI6Z08vWme0$  or something)


I see no reason why this cannot be done. No explicit comment was made when I was asking about this within related issue, so the easiest and fastest way was taken.



Well, this is the way it is since EclipseLink 2.5.1 at least, probably since the time this feature was introduced around EclipseLink 2.4.2. There may be even bug filed for this somewhere.


Granted it's been called
`org.eclipse.persistence:org.eclipse.persistence.jpa.modelgen.processor`
in maven for a very long time. My only point is that it has also been
called `org.eclipse.persistence.jpa.modelgen_*.jar` and
`Bundle-SymbolicName: org.eclipse.persistence.jpa.modelgen` for just
as long. Just inconsistent.


I think this is fixed in master/3.x. I don’t think there is good enough justification for this change which outweighs potential risk in 2.7.x and necessary updates all over docs, wikis and other places

Thanks,
—lukas


Thanks,
Will Dazey

On Mon, Jul 26, 2021 at 11:12 AM Lukas Jungmann
<lukas.jungmann@xxxxxxxxxx> wrote:


On 7/26/21 5:07 PM, William Dazey wrote:

Hello!


No, it is intentional. eclipselink 2.7.9 uses

org.eclipse.persistence:org.eclipse.persistence.asm:9.1.0


How is that indicated in

https://urldefense.com/v3/__https://www.eclipse.org/downloads/download.php?file=*rt*eclipselink*releases*2.7.9*eclipselink-plugins-2.7.9.v20210604-2c549e2208.zip__;Ly8vLy8!!ACWV5N9M2RV99hQ!YiPSFL1bj2w4dTEV8gt3OLrTCUWLFpg0rARQArj0Kvmt9MYYAf1HGvB8sI6Z2piyxUM$

<https://urldefense.com/v3/__https://www.eclipse.org/downloads/download.php?file=*rt*eclipselink*releases*2.7.9*eclipselink-plugins-2.7.9.v20210604-2c549e2208.zip__;Ly8vLy8!!ACWV5N9M2RV99hQ!eSOjYOMvm0BH_b4656J9Q_vkopUw3ce2xvSgNsIlAMnGN0-LgaTme8wlF1QATjKrh34$>?

Almost nothing has changed in the MANIFEST.MF and now the jar is just

called `org.eclipse.persistence.asm.jar`. Compared to

`https://urldefense.com/v3/__https://www.eclipse.org/downloads/download.php?file=*rt*eclipselink*releases*2.7.8*eclipselink-plugins-2.7.8.v20201217-ecdf3c32c4.zip__;Ly8vLy8!!ACWV5N9M2RV99hQ!YiPSFL1bj2w4dTEV8gt3OLrTCUWLFpg0rARQArj0Kvmt9MYYAf1HGvB8sI6Zrhw858o$ `

<https://urldefense.com/v3/__https://www.eclipse.org/downloads/download.php?file=*rt*eclipselink*releases*2.7.8*eclipselink-plugins-2.7.8.v20201217-ecdf3c32c4.zip*60__;Ly8vLy8l!!ACWV5N9M2RV99hQ!eSOjYOMvm0BH_b4656J9Q_vkopUw3ce2xvSgNsIlAMnGN0-LgaTme8wlF1QApjq-veY$>,

I don't see anything that changed to indicate this version convention

change on maven central. Maybe the JAR bundle name should be

`org.eclipse.persistence.asm_9.1.0.v20210604-2c549e2208.jar`?


Do you think it would be better to keep publishing the same binary

under 2, 3, 4+ different version numbers - one for 2.6 stream, one for

2.7, another for 3.0 and in foreseeable also one for 3.1, generally,

going forward, one for each maintained version stream - in maven central

instead of having just one binary there and letting all streams to

depend on that one? All streams see o.e.p.asm just as any other

3rd-party library, like gmbal or most api jars (jakarta.*jar) - so if

one looks at it from that perspective, the naming is consistent with

others. It's just the name what reflects the reality wrt origin of the

file and its relationship to EclipseLink project.


The other difference you see (the qualifier dis-appearance) is caused by

the switch from Tycho to Maven. Tycho uses, in most cases,

manifest-first approach to build artifacts and, in general, works with

qualifiers instead of "SNAPSHOT"s to bring in ability to differentiate 2

different nightly builds. Maven has no such notion and generally uses

just snapshots for them providing no "default" way to easily

differentiate 2 different SNAPSHOT builds.




And no update for ANTRL as well? That hasn't changed from version 3.5.2

for years and we still use '2.7.8', '2.7.9', ect. Granted EclipseLink >=

3.0 doesn't use ANTRL anymore, but 2.7 does. Feels inconsistent for 2.7.


I agree that it feels inconsistent. Nobody touched that part of the

build for about a decade, it's still being rebuilt and republished on

each release. The only change there I recall was an upgrade of ANTLR

from sth like 3.2 to 3.5.2 and/or some clean up there in EclipseLink

2.5.2 timeframe.


(there used to be class files directly checked in in the repo for both

ASM as well as ANTLR before 2.5.2)



Also, comparing Maven Central with

`https://urldefense.com/v3/__https://www.eclipse.org/downloads/download.php?file=*rt*eclipselink*releases__;Ly8v!!ACWV5N9M2RV99hQ!YiPSFL1bj2w4dTEV8gt3OLrTCUWLFpg0rARQArj0Kvmt9MYYAf1HGvB8sI6ZbYUk0ko$ `

<https://urldefense.com/v3/__https://www.eclipse.org/downloads/download.php?file=*rt*eclipselink*releases*60__;Ly8vJQ!!ACWV5N9M2RV99hQ!eSOjYOMvm0BH_b4656J9Q_vkopUw3ce2xvSgNsIlAMnGN0-LgaTme8wlF1QAM2O4y5Q$>

I notice another difference. In the `eclipse.org/downloads`

<https://urldefense.com/v3/__http://eclipse.org/downloads*60__;JQ!!ACWV5N9M2RV99hQ!eSOjYOMvm0BH_b4656J9Q_vkopUw3ce2xvSgNsIlAMnGN0-LgaTme8wlF1QANblE-cQ$>

artifacts,

the `org.eclipse.persistence.jpa.modelgen` bundle is called

`org.eclipse.persistence.jpa.modelgen_2.7.9.v20210604-2c549e2208.jar`

and the Manifest also indicates the bundle name to be

`org.eclipse.persistence.jpa.modelgen`:

```

      Bundle-Name: EclipseLink JPA ModelGen

Bundle-SymbolicName: org.eclipse.persistence.jpa.modelgen

Bundle-Vendor: Eclipse.org - EclipseLink Project

Bundle-Version: 2.7.9.v20210604-2c549e2208

```


However, on maven central, the we give the artifact an ID of

`org.eclipse.persistence.jpa.modelgen.processor`

(https://urldefense.com/v3/__https://mvnrepository.com/artifact/org.eclipse.persistence/org.eclipse.persistence.jpa.modelgen.processor__;!!ACWV5N9M2RV99hQ!YiPSFL1bj2w4dTEV8gt3OLrTCUWLFpg0rARQArj0Kvmt9MYYAf1HGvB8sI6ZxJqwVYE$

<https://urldefense.com/v3/__https://mvnrepository.com/artifact/org.eclipse.persistence/org.eclipse.persistence.jpa.modelgen.processor__;!!ACWV5N9M2RV99hQ!eSOjYOMvm0BH_b4656J9Q_vkopUw3ce2xvSgNsIlAMnGN0-LgaTme8wlF1QABj2AAEo$>)?

Can we get this inconsistency fixed because it's a bit confusing what

the true name of this bundle is supposed to be


Well, this is the way it is since EclipseLink 2.5.1 at least, probably

since the time this feature was introduced around EclipseLink 2.4.2.

There may be even bug filed for this somewhere.


thanks,

--lukas



Thanks,

Will Dazey



On Wed, Jul 21, 2021 at 12:54 PM Lukas Jungmann

<lukas.jungmann@xxxxxxxxxx <mailto:lukas.jungmann@xxxxxxxxxx>> wrote:


     On 7/21/21 6:37 PM, Jody Grassel wrote:

I was checking maven central, and noticed there were no resources

     for

the maven coordinate

"org.eclipse.persistence:org.eclipse.persistence.asm:2.7.9" -- is

     this

an omission?


     No, it is intention. eclipselink 2.7.9 uses

     org.eclipse.persistence:org.eclipse.persistence.asm:9.1.0 - same

     version

     as master and/or 3.0.2.


     thanks,

     --lukas



_______________________________________________

eclipselink-dev mailing list

eclipselink-dev@xxxxxxxxxxx <mailto:eclipselink-dev@xxxxxxxxxxx>

To unsubscribe from this list, visit

     https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!c282CiRmzlMujtr4Dr0XaiYSiIHmAxdDiXr9s4MI2haeGi5LjKioaMf51c4a3t1ApQQ$

     <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!c282CiRmzlMujtr4Dr0XaiYSiIHmAxdDiXr9s4MI2haeGi5LjKioaMf51c4a3t1ApQQ$>



     _______________________________________________

     eclipselink-dev mailing list

     eclipselink-dev@xxxxxxxxxxx <mailto:eclipselink-dev@xxxxxxxxxxx>

     To unsubscribe from this list, visit

     https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!YiPSFL1bj2w4dTEV8gt3OLrTCUWLFpg0rARQArj0Kvmt9MYYAf1HGvB8sI6ZCGh5cs4$

     <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!eSOjYOMvm0BH_b4656J9Q_vkopUw3ce2xvSgNsIlAMnGN0-LgaTme8wlF1QAcJRNF-w$>



_______________________________________________

eclipselink-dev mailing list

eclipselink-dev@xxxxxxxxxxx

To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!eSOjYOMvm0BH_b4656J9Q_vkopUw3ce2xvSgNsIlAMnGN0-LgaTme8wlF1QAcJRNF-w$



_______________________________________________

eclipselink-dev mailing list

eclipselink-dev@xxxxxxxxxxx

To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!YiPSFL1bj2w4dTEV8gt3OLrTCUWLFpg0rARQArj0Kvmt9MYYAf1HGvB8sI6ZCGh5cs4$

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!YiPSFL1bj2w4dTEV8gt3OLrTCUWLFpg0rARQArj0Kvmt9MYYAf1HGvB8sI6ZCGh5cs4$

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!bmjB3firWfdbMtPoVoyHE5hnAlHfhq712cvomfMP4Nvnn6TJFehFb5skdUyS_q25kP0$

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!bmjB3firWfdbMtPoVoyHE5hnAlHfhq712cvomfMP4Nvnn6TJFehFb5skdUyS_q25kP0$



_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!cU8Y8-G0Z_Yddte9BkjjbP9yDF17HMxGuDglUar2JvOQCzIfZVnxEDGfRXlz8DUYLW4$

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!cU8Y8-G0Z_Yddte9BkjjbP9yDF17HMxGuDglUar2JvOQCzIfZVnxEDGfRXlz8DUYLW4$

Back to the top