persistence@glassfish.java.net

Re: Please review: changes to push new versions to maven repository

From: Lance J. Andersen <Lance.Andersen_at_Sun.COM>
Date: Tue, 13 Feb 2007 10:12:21 -0500

Hi Craig,

Craig L Russell wrote:
> Hi Marina,
>
> On Feb 12, 2007, at 5:10 PM, Marina Vatkina wrote:
>
>> Hi Craig,
>>
>> Craig L Russell wrote:
>>> Hi Marina,
>>> On Feb 12, 2007, at 3:57 PM, Marina Vatkina wrote:
>>>> Hi Craig,
>>>>
>>>> I agree with your item #1. Do you know if it's possible to move
>>>> existing toplink-essentialsXXX.jar (and other artifacts) to a new
>>>> id when it's created? Otherwise it can be even bigger issue with
>>>> spreading versions across groupIds.
>>> The groupId is part of the maven pom that you set up. I don't know
>>> of any issues with different parts of the system having the same
>>> groupId. There might be extra work in case you decide to package
>>> both the implementation and the agent in the same jar. Then, you
>>> would have to rework the jar packaging step.
>>
>> The jar packaging step already adds javax.persistence classes to the
>> toplink jar. My concern was that if I change the group id (in the
>> pom), there will be old TLE jars under javax.persistence and the new
>> ones under e.g. the oracle.toplink.essentials and it can confuse the
>> users.
>
> To avoid confusion, you could always delete the old ones that are in
> the wrong place. The only folks who are affected are new users (maven
> only downloads the artifacts once) who should use the new artifact
> locations.
Maven does not allow for the replacing of existing jars in the repository.
>>
>>>>
>>>> The original persistence-api jar (your point #3) was final but
>>>> contained several signature bugs (as compared with the spec) that
>>>> had been fixed since then.
>>> As far as I know, the only proper way to make changes to
>>> JCP-released and JCP-voted artifacts is to make a maintenance
>>> release. So we are in violation of JCP rules if we changed a jar
>>> after the JCP voted on the artifacts.
>>> So the version number might need to be something like 1.0.1 or
>>> somesuch and the JCP will have to approve the maintenance release.
>>> Not My Rules.
This is not true. If we were changing the spec, then yes, an MR would
have to be released. The RI can continue to evolve to address bugs
found in the implementation. This does not require an MR either.
>>
>> I don't change the rules or the spec.
>
> Please read the JCP process. You cannot change the spec, RI, or TCK
> after the final vote.
You can update the RI and the TCK after the spec goes final. Based on
a test challenge, the test will either be excluded or patched, based on
the analysis of the TCK team. Signature issues must always be addressed
when/if they are uncovered by patching.
>
>> We hadn't notice (in time to do it for 1.0) that the API classes
>> didn't match the spec in several (minor) cases. We fixed those
>> classes so that they match the spec.
>
> That's what the Maintenance Review is all about. You don't have a
> choice in this.
The MR does not come into play for a bug in the RI. It comes into play
when a change is required to the spec.
>
> By the way, this is why the TCK is not simply updated anytime someone
> successfully challenges a test case.
Tests can be patched if that is decided to be the correct course of
action by the TCK team as outlined above.


Regards
Lance
>
> Craig
>>
>> thanks,
>> -marina
>>
>>> :-(
>>> Craig
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>> Craig L Russell wrote:
>>>>
>>>>> Hi Marina,
>>>>> Just a few comments.
>>>>> 1. There are two groups of code here: the standard and the
>>>>> toplink implementation. It would be better if we grouped them as
>>>>> such:
>>>>> groupId javax.persistence: contains persistence-apiXXX.jar as in
>>>>> your proposal
>>>>> groupId toplink.essentials: should contain toplink-
>>>>> essentialsXXX.jar and toplink-essentials-agentXXX.jar
>>>>> 2. I like the toplink version notation including the build number.
>>>>> 3. It is a shame the original persistence-api jar was published
>>>>> with a version number of 1.0 when it was not final. I don't have
>>>>> a good alternative to 1.0b even though I hate it.
>>>>> Craig
>>>>> On Feb 8, 2007, at 6:52 PM, Marina Vatkina wrote:
>>>>>
>>>>>> I made the following changes to create jars with a new version:
>>>>>>
>>>>>> 1. Changed version of the persistence-api related files to 1.0b
>>>>>> in persistence-api:
>>>>>> Index: build.properties
>>>>>> ===================================================================
>>>>>> RCS file: /cvs/glassfish/persistence-api/build.properties,v
>>>>>> retrieving revision 1.4
>>>>>> diff -r1.4 build.properties
>>>>>> 29c29
>>>>>> < release.version=1.0
>>>>>> ---
>>>>>> > release.version=1.0b
>>>>>>
>>>>>> 2. Changed version of the toplink related files to 2.0-35 and
>>>>>> the dependency on the p-api to 1.0b in entity-persistence:
>>>>>>
>>>>>> Index: build.properties
>>>>>> ===================================================================
>>>>>> RCS file: /cvs/glassfish/entity-persistence/build.properties,v
>>>>>> retrieving revision 1.2
>>>>>> diff -r1.2 build.properties
>>>>>> 29c29
>>>>>> < release.version=1.0
>>>>>> ---
>>>>>> > release.version=2.0-35
>>>>>> Index: toplink-essentials.pom
>>>>>> ===================================================================
>>>>>> RCS file: /cvs/glassfish/entity-persistence/toplink-essentials.pom,v
>>>>>> retrieving revision 1.1
>>>>>> diff -r1.1 toplink-essentials.pom
>>>>>> 10c10
>>>>>> < <version>1.0</version>
>>>>>> ---
>>>>>> > <version>1.0b</version>
>>>>>>
>>>>>> I tested by creating the files without pushing them to the
>>>>>> repository. Their names look correct:
>>>>>>
>>>>>> persistence-api/build/maven-repo/javax.persistence/jars/
>>>>>> persistence- api-1.0b.jar
>>>>>> persistence-api/build/maven-repo/javax.persistence/jars/
>>>>>> persistence- api-1.0b.jar.md5
>>>>>> persistence-api/build/maven-repo/javax.persistence/poms/
>>>>>> persistence- api-1.0b.pom
>>>>>> persistence-api/build/maven-repo/javax.persistence/poms/
>>>>>> persistence- api-1.0b.pom.md5
>>>>>> persistence-api/build/maven-repo/javax.persistence/java-sources/
>>>>>> persistence-api-1.0b-sources.jar
>>>>>> persistence-api/build/maven-repo/javax.persistence/java-sources/
>>>>>> persistence-api-1.0b-sources.jar.md5
>>>>>>
>>>>>> entity-persistence/build/maven-repo/javax.persistence/jars/
>>>>>> toplink- essentials-2.0-35.jar
>>>>>> entity-persistence/build/maven-repo/javax.persistence/jars/
>>>>>> toplink- essentials-2.0-35.jar.md5
>>>>>> entity-persistence/build/maven-repo/javax.persistence/poms/
>>>>>> toplink- essentials-2.0-35.pom
>>>>>> entity-persistence/build/maven-repo/javax.persistence/poms/
>>>>>> toplink- essentials-2.0-35.pom.md5
>>>>>> entity-persistence/build/maven-repo/javax.persistence/java-
>>>>>> sources/ toplink-essentials-2.0-35-sources.jar
>>>>>> entity-persistence/build/maven-repo/javax.persistence/java-
>>>>>> sources/ toplink-essentials-2.0-35-sources.jar.md5
>>>>>> entity-persistence/build/maven-repo/
>>>>>> oracle.toplink.essentials.agent/ jars/toplink-essentials-
>>>>>> agent-2.0-35.jar
>>>>>> entity-persistence/build/maven-repo/
>>>>>> oracle.toplink.essentials.agent/ jars/toplink-essentials-
>>>>>> agent-2.0-35.jar.md5
>>>>>> entity-persistence/build/maven-repo/
>>>>>> oracle.toplink.essentials.agent/ poms/toplink-essentials-
>>>>>> agent-2.0-35.pom
>>>>>> entity-persistence/build/maven-repo/
>>>>>> oracle.toplink.essentials.agent/ poms/toplink-essentials-
>>>>>> agent-2.0-35.pom.md5
>>>>>> entity-persistence/build/maven-repo/
>>>>>> oracle.toplink.essentials.agent/ java-sources/toplink-essentials-
>>>>>> agent-2.0-35-sources.jar
>>>>>> entity-persistence/build/maven-repo/
>>>>>> oracle.toplink.essentials.agent/ java-sources/toplink-essentials-
>>>>>> agent-2.0-35-sources.jar.md5
>>>>>>
>>>>>>
>>>>>> thanks,
>>>>>> -marina
>>>>>> <mavenized-changes.jar>
>>>>>
>>>>> Craig Russell
>>>>> Architect, Sun Java Enterprise System
>>>>> http://java.sun.com/products/ jdo
>>>>> 408 276-5638 mailto:Craig.Russell_at_sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell_at_sun.com
>>> P.S. A good JDO? O, Gasp!
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell_at_sun.com
> P.S. A good JDO? O, Gasp!
>