juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kurt T Stam <kurt.s...@gmail.com>
Subject Re: Problem with how uddi-ws build works and maven snapshots
Date Fri, 17 Jun 2011 20:03:47 GMT
On 6/17/11 9:26 AM, Kurt T Stam wrote:
> On 6/16/11 8:03 PM, David Jencks wrote:
>>
>> On Jun 16, 2011, at 2:42 PM, Kurt Stam wrote:
>>
>>> Hi David,
>>>
>>> You should be able to specify a jaxws21 classifier to get the 
>>> jaxws21 version?
>>
>> Hi Kurt,
>>
>> I might not have explained the problem very well.  However, I 
>> compared the jars I got from (no profile) and -Pjaxws21 and the only 
>> difference I can see is in some maven files, the class files all have 
>> the same size so I'd guess they are identical.  Can you explain what 
>> the difference is?  Usually a possibly different dependency is not a 
>> good enough reason to add a classifier.  I'd suggest compiling with 
>> the jaxws 2.1 spec and marking it as provided so the user can supply 
>> whatever spec they want.  Also, does this stuff really require jaxb 
>> 2.2?  I'd guess that since it works with jaxws 2.1 it doesn't.
>>
>> Anyway.... back the the problem I think is happening (but haven't 
>> verified).
>>
>> When you run mvn deploy it updates the maven-metadata.xml to indicate 
>> the timestamp and build number of the uploaded snapshot artifacts. 
>>  When maven tries to download a "SNAPSHOT" it looks at this metadata 
>> to find the most recent upload.  So, after I just pushed a plain 
>> uddi-ws-3.1.0-SNAPSHOT.jar the metadata looks like this:
>>
>> <metadata  modelVersion="1.1.0">
>>    <groupId>org.apache.juddi</groupId>
>>    <artifactId>uddi-ws</artifactId>
>>    <version>3.1.0-SNAPSHOT</version>
>>    <versioning>
>>      <snapshot>
>>        <timestamp>20110616.210535</timestamp>
>>        <buildNumber>16</buildNumber>
>>      </snapshot>
>>      <lastUpdated>20110616210535</lastUpdated>
>>      <snapshotVersions>
>>        <snapshotVersion>
>>          <extension>jar</extension>
>>          <value>3.1.0-20110616.210535-16</value>
>>          <updated>20110616210535</updated>
>>        </snapshotVersion>
>>        <snapshotVersion>
>>          <extension>pom</extension>
>>          <value>3.1.0-20110616.210535-16</value>
>>          <updated>20110616210535</updated>
>>        </snapshotVersion>
>>      </snapshotVersions>
>>    </versioning>
>> </metadata>
>> The previously existing uddi-ws-3.1.0-SNAPSHOT-jaxws21.jar 
>> <https://repository.apache.org/content/repositories/snapshots/org/apache/juddi/uddi-ws/3.1.0-SNAPSHOT/uddi-ws-3.1.0-SNAPSHOT-jaxws21.jar>
still 
>> there but not mentioned in the metadata so I think it may be 
>> inaccessible.  On the other hand somehow it got into the repo without 
>> a timestamp which I thought was impossible so I could be wrong.
>>
>> I'd still like to understand what the 2 ways of building the jar are for.
>>
>> thanks!
>> david jencks
>>
>>
> Hi David,
>
> If you deploy the uddi-ws.jar compiled against jaxws-2.2 to an 
> environment where the jaxws-2.1 interfaces are used, then you will get 
> linkage errors (missing methods). I'm talking older appservers here. 
> So in short, our code maybe the same in both versions of the jar but 
> the byte code produced is slightly different.
>
> At release time I ran
>
> mvn clean deploy -Papache-release -Pjaxws21
>
> to add the jaxws21 version of the jar. But as you found out, this 
> seems to mess with the meta data.
>
> I'm open for suggestions on how to support this properly. Aren't 
> classifiers used to support different jdk versions?
>
> Cheers,
>
> --Kurt

David,

OK after re-testing it turns out we don't need the different compile. 
Your assessment that the jars end up the same
was true. Not entirely sure how we got to our conclusion we needed it 
before, but things are working now.

Do you see any more issues before I start another vote?

Cheers,

--Kurt



Mime
View raw message