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?


26. 7. 2021 v 22:30, William Dazey <dazeydev.3@xxxxxxxxx>:


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?

Where were you trying to find it? Did you try search through issues or PRs or looked into pom of released artifact or any other way? https://github.com/eclipse-ee4j/eclipselink/commits/master/plugins/org.eclipse.persistence.asm has full history together with few back pointers to PRs and issues


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?

Always from master on as needed basis. It’s completely independent on the other parts of the repo. 



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?

All jobs are at https://ci.eclipse.org/eclipselink/ - your (or any other committer) eclipse account profile page has a pointer to all CIs particular person has access to. Write and exec access to CI server is restricted to project committers only.

More info at https://www.eclipse.org/projects/handbook/ - a resource every committer is supposed to be aware of


Is that code checked
into any release branches?

Does it matter when it is NOT part of the release nor any other kind of the build? Should we exclude all other irrelevant files, like md files, various readmes, project-admin stuff etc from all branches as well? This is not SVN where this would be easy to do. In git it just does not make sense to deal with this as the overhead this brings is marginal - at least AFAIK

Thanks,
—lukas


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!aYJuH0RupOPB_gmT6OmyZJZ8fkjPP88HRFMUr4YArXNMnV9D0-cBE0oJYtjfx-p9ndU$  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!aYJuH0RupOPB_gmT6OmyZJZ8fkjPP88HRFMUr4YArXNMnV9D0-cBE0oJYtjfXlW5mrQ$
_______________________________________________
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!aYJuH0RupOPB_gmT6OmyZJZ8fkjPP88HRFMUr4YArXNMnV9D0-cBE0oJYtjfXlW5mrQ$

Back to the top