6856630: Restructure jaxp/jaxws repository
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 | Next > |
 |
6856630: Restructure jaxp/jaxws repository
by Kelly O'Hair
::
Rate this Message:
This 6856630 change has been integrated into the build forest jaxp and jaxws repositories: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/ae2bec597586 http://hg.openjdk.java.net/jdk7/build/jaxp/rev/534e23823a1b Assuming we get successful test builds of the build forest, these changes will get integrated into the jdk7 master forest. Notes: * The jaxws (and jaf) and jaxp sources have been extracted and put into separate source zip files. These zip files represent the source deliveries into the jdk7 project. Selection of the bundles is determined by the properties in the files jax*/jax*.properties and jax*/build-defs.xml. The current 3 source drop bundles are: jdk7-jaf-2009_08_28.zip jdk7-jaxp-2009_08_28.zip jdk7-jaxws-2009_08_28.zip If not found in the /java/devtools/share/jdk7-drops directory, the ant scripts will look for them at http://kenai.com/projects/jdk7-drops/downloads a temporary site for now until the JAX* teams engage. * The original jaxp/src and jaxws/src files are still there, but should not be used unless the drop source bundles are unavailable (currently the drop bundles contain the exact same files). A warning will be issued if they are used. Eventually the original jaxp/src and jaxws/src files will be deleted from the jdk7 repositories. * 'ant source' or 'cd make && make source' will get the drop bundles and populate the drop source area. But this should happen automatically. Please ask questions, this is kind of a big change and anything can go wrong, please let me know if there are problems. -kto |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by gnu_andrew
::
Rate this Message:
2009/9/22 Kelly O'Hair <Kelly.Ohair@...>:
> > This 6856630 change has been integrated into the build > forest jaxp and jaxws repositories: > > http://hg.openjdk.java.net/jdk7/build/jaxws/rev/ae2bec597586 > http://hg.openjdk.java.net/jdk7/build/jaxp/rev/534e23823a1b > > Assuming we get successful test builds of the build forest, these > changes will get integrated into the jdk7 master forest. > > Notes: > * The jaxws (and jaf) and jaxp sources have been extracted and > put into separate source zip files. These zip files represent > the source deliveries into the jdk7 project. Selection of > the bundles is determined by the properties in the files > jax*/jax*.properties and jax*/build-defs.xml. > The current 3 source drop bundles are: > jdk7-jaf-2009_08_28.zip > jdk7-jaxp-2009_08_28.zip > jdk7-jaxws-2009_08_28.zip > If not found in the /java/devtools/share/jdk7-drops directory, > the ant scripts will look for them at > http://kenai.com/projects/jdk7-drops/downloads > a temporary site for now until the JAX* teams engage. > > * The original jaxp/src and jaxws/src files are still there, > but should not be used unless the drop source bundles are > unavailable (currently the drop bundles contain the exact > same files). A warning will be issued if they are used. > Eventually the original jaxp/src and jaxws/src files will > be deleted from the jdk7 repositories. > > * 'ant source' or 'cd make && make source' will get the drop > bundles and populate the drop source area. But this should > happen automatically. > > Please ask questions, this is kind of a big change and anything > can go wrong, please let me know if there are problems. > > -kto > > Hi Kelly, This patch is now in b73 and I'm trying to get IcedTea7 to build with it. How do I specify the location of the zips to use? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by gnu_andrew
::
Rate this Message:
2009/10/7 Andrew John Hughes <gnu_andrew@...>:
> 2009/9/22 Kelly O'Hair <Kelly.Ohair@...>: >> >> This 6856630 change has been integrated into the build >> forest jaxp and jaxws repositories: >> >> http://hg.openjdk.java.net/jdk7/build/jaxws/rev/ae2bec597586 >> http://hg.openjdk.java.net/jdk7/build/jaxp/rev/534e23823a1b >> >> Assuming we get successful test builds of the build forest, these >> changes will get integrated into the jdk7 master forest. >> >> Notes: >> * The jaxws (and jaf) and jaxp sources have been extracted and >> put into separate source zip files. These zip files represent >> the source deliveries into the jdk7 project. Selection of >> the bundles is determined by the properties in the files >> jax*/jax*.properties and jax*/build-defs.xml. >> The current 3 source drop bundles are: >> jdk7-jaf-2009_08_28.zip >> jdk7-jaxp-2009_08_28.zip >> jdk7-jaxws-2009_08_28.zip >> If not found in the /java/devtools/share/jdk7-drops directory, >> the ant scripts will look for them at >> http://kenai.com/projects/jdk7-drops/downloads >> a temporary site for now until the JAX* teams engage. >> >> * The original jaxp/src and jaxws/src files are still there, >> but should not be used unless the drop source bundles are >> unavailable (currently the drop bundles contain the exact >> same files). A warning will be issued if they are used. >> Eventually the original jaxp/src and jaxws/src files will >> be deleted from the jdk7 repositories. >> >> * 'ant source' or 'cd make && make source' will get the drop >> bundles and populate the drop source area. But this should >> happen automatically. >> >> Please ask questions, this is kind of a big change and anything >> can go wrong, please let me know if there are problems. >> >> -kto >> >> > > Hi Kelly, > > This patch is now in b73 and I'm trying to get IcedTea7 to build with > it. How do I specify the location of the zips to use? > > Thanks, > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > I found a number of issues with the current version: * The drop zips are expected to be in a share/jdk7-drops subdirectory of the devtools directory. This doesn't really work outside Sun's internal setup. I've added support for ALT_DROP_DIR which can be used to specify an exact path to the zips. If this is not set, the old devtools behaviour is used. * The zips are being downloaded and extracted in the source directory, which could be read only. I've changed this so they are written to the build directory like everything else. The webrev for these changes is here: http://cr.openjdk.java.net/~andrew/drops/webrev.01/ I've committed this to IcedTea already. Does this look ok for build also? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by Kelly O'Hair
::
Rate this Message:
I can't see the webrev right now due to the server issues.
As soon as I can look at it I'll let you know. At first I wondered if it should be named ALT_JDK7_DROP_DIR, but then I thought not, and I should have used jdk-drops instead of jdk7-drops, getting the version out of the directory. The file names should make them unique enough. So your change may be fine as is, as soon as I can see it. ;^) And I apologize for not creating an ALT_* setting before... my oversight. -kto Andrew John Hughes wrote: > 2009/10/7 Andrew John Hughes <gnu_andrew@...>: >> 2009/9/22 Kelly O'Hair <Kelly.Ohair@...>: >>> This 6856630 change has been integrated into the build >>> forest jaxp and jaxws repositories: >>> >>> http://hg.openjdk.java.net/jdk7/build/jaxws/rev/ae2bec597586 >>> http://hg.openjdk.java.net/jdk7/build/jaxp/rev/534e23823a1b >>> >>> Assuming we get successful test builds of the build forest, these >>> changes will get integrated into the jdk7 master forest. >>> >>> Notes: >>> * The jaxws (and jaf) and jaxp sources have been extracted and >>> put into separate source zip files. These zip files represent >>> the source deliveries into the jdk7 project. Selection of >>> the bundles is determined by the properties in the files >>> jax*/jax*.properties and jax*/build-defs.xml. >>> The current 3 source drop bundles are: >>> jdk7-jaf-2009_08_28.zip >>> jdk7-jaxp-2009_08_28.zip >>> jdk7-jaxws-2009_08_28.zip >>> If not found in the /java/devtools/share/jdk7-drops directory, >>> the ant scripts will look for them at >>> http://kenai.com/projects/jdk7-drops/downloads >>> a temporary site for now until the JAX* teams engage. >>> >>> * The original jaxp/src and jaxws/src files are still there, >>> but should not be used unless the drop source bundles are >>> unavailable (currently the drop bundles contain the exact >>> same files). A warning will be issued if they are used. >>> Eventually the original jaxp/src and jaxws/src files will >>> be deleted from the jdk7 repositories. >>> >>> * 'ant source' or 'cd make && make source' will get the drop >>> bundles and populate the drop source area. But this should >>> happen automatically. >>> >>> Please ask questions, this is kind of a big change and anything >>> can go wrong, please let me know if there are problems. >>> >>> -kto >>> >>> >> Hi Kelly, >> >> This patch is now in b73 and I'm trying to get IcedTea7 to build with >> it. How do I specify the location of the zips to use? >> >> Thanks, >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> > > I found a number of issues with the current version: > > * The drop zips are expected to be in a share/jdk7-drops subdirectory > of the devtools directory. This doesn't really work outside Sun's > internal setup. I've added support for ALT_DROP_DIR which can be used > to specify an exact path to the zips. If this is not set, the old > devtools behaviour is used. > * The zips are being downloaded and extracted in the source directory, > which could be read only. I've changed this so they are written to > the build directory like everything else. > > The webrev for these changes is here: > > http://cr.openjdk.java.net/~andrew/drops/webrev.01/ > > I've committed this to IcedTea already. Does this look ok for build also? |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by tim.bell
::
Rate this Message:
Kelly O'Hair wrote:
> I can't see the webrev right now due to the server issues. % date Fri Oct 9 15:08:00 PDT 2009 The fact that we all got this email, and that I can load up http://cr.openjdk.java.net/~andrew/drops/webrev.01/ Makes me hopeful that the .ojn servers are back online. But - your mileage may vary. We do not have an official 'all clear' message yet. Tim > As soon as I can look at it I'll let you know. > > At first I wondered if it should be named ALT_JDK7_DROP_DIR, > but then I thought not, and I should have used jdk-drops > instead of jdk7-drops, getting the version out of the directory. > The file names should make them unique enough. > > So your change may be fine as is, as soon as I can see it. ;^) > > And I apologize for not creating an ALT_* setting before... my oversight. > > -kto > > Andrew John Hughes wrote: >> 2009/10/7 Andrew John Hughes <gnu_andrew@...>: >>> 2009/9/22 Kelly O'Hair <Kelly.Ohair@...>: >>>> This 6856630 change has been integrated into the build >>>> forest jaxp and jaxws repositories: >>>> >>>> http://hg.openjdk.java.net/jdk7/build/jaxws/rev/ae2bec597586 >>>> http://hg.openjdk.java.net/jdk7/build/jaxp/rev/534e23823a1b >>>> >>>> Assuming we get successful test builds of the build forest, these >>>> changes will get integrated into the jdk7 master forest. >>>> >>>> Notes: >>>> * The jaxws (and jaf) and jaxp sources have been extracted and >>>> put into separate source zip files. These zip files represent >>>> the source deliveries into the jdk7 project. Selection of >>>> the bundles is determined by the properties in the files >>>> jax*/jax*.properties and jax*/build-defs.xml. >>>> The current 3 source drop bundles are: >>>> jdk7-jaf-2009_08_28.zip >>>> jdk7-jaxp-2009_08_28.zip >>>> jdk7-jaxws-2009_08_28.zip >>>> If not found in the /java/devtools/share/jdk7-drops directory, >>>> the ant scripts will look for them at >>>> http://kenai.com/projects/jdk7-drops/downloads >>>> a temporary site for now until the JAX* teams engage. >>>> >>>> * The original jaxp/src and jaxws/src files are still there, >>>> but should not be used unless the drop source bundles are >>>> unavailable (currently the drop bundles contain the exact >>>> same files). A warning will be issued if they are used. >>>> Eventually the original jaxp/src and jaxws/src files will >>>> be deleted from the jdk7 repositories. >>>> >>>> * 'ant source' or 'cd make && make source' will get the drop >>>> bundles and populate the drop source area. But this should >>>> happen automatically. >>>> >>>> Please ask questions, this is kind of a big change and anything >>>> can go wrong, please let me know if there are problems. >>>> >>>> -kto >>>> >>>> >>> Hi Kelly, >>> >>> This patch is now in b73 and I'm trying to get IcedTea7 to build with >>> it. How do I specify the location of the zips to use? >>> >>> Thanks, >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>> >> I found a number of issues with the current version: >> >> * The drop zips are expected to be in a share/jdk7-drops subdirectory >> of the devtools directory. This doesn't really work outside Sun's >> internal setup. I've added support for ALT_DROP_DIR which can be used >> to specify an exact path to the zips. If this is not set, the old >> devtools behaviour is used. >> * The zips are being downloaded and extracted in the source directory, >> which could be read only. I've changed this so they are written to >> the build directory like everything else. >> >> The webrev for these changes is here: >> >> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >> >> I've committed this to IcedTea already. Does this look ok for build also? |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by gnu_andrew
::
Rate this Message:
2009/10/9 Kelly O'Hair <Kelly.Ohair@...>:
> I can't see the webrev right now due to the server issues. > > As soon as I can look at it I'll let you know. > > At first I wondered if it should be named ALT_JDK7_DROP_DIR, > but then I thought not, and I should have used jdk-drops > instead of jdk7-drops, getting the version out of the directory. > The file names should make them unique enough. > > So your change may be fine as is, as soon as I can see it. ;^) > I can access it fine from here now. > And I apologize for not creating an ALT_* setting before... my oversight. > No problem; easily fixed. > -kto > > Andrew John Hughes wrote: >> >> 2009/10/7 Andrew John Hughes <gnu_andrew@...>: >>> >>> 2009/9/22 Kelly O'Hair <Kelly.Ohair@...>: >>>> >>>> This 6856630 change has been integrated into the build >>>> forest jaxp and jaxws repositories: >>>> >>>> http://hg.openjdk.java.net/jdk7/build/jaxws/rev/ae2bec597586 >>>> http://hg.openjdk.java.net/jdk7/build/jaxp/rev/534e23823a1b >>>> >>>> Assuming we get successful test builds of the build forest, these >>>> changes will get integrated into the jdk7 master forest. >>>> >>>> Notes: >>>> * The jaxws (and jaf) and jaxp sources have been extracted and >>>> put into separate source zip files. These zip files represent >>>> the source deliveries into the jdk7 project. Selection of >>>> the bundles is determined by the properties in the files >>>> jax*/jax*.properties and jax*/build-defs.xml. >>>> The current 3 source drop bundles are: >>>> jdk7-jaf-2009_08_28.zip >>>> jdk7-jaxp-2009_08_28.zip >>>> jdk7-jaxws-2009_08_28.zip >>>> If not found in the /java/devtools/share/jdk7-drops directory, >>>> the ant scripts will look for them at >>>> http://kenai.com/projects/jdk7-drops/downloads >>>> a temporary site for now until the JAX* teams engage. >>>> >>>> * The original jaxp/src and jaxws/src files are still there, >>>> but should not be used unless the drop source bundles are >>>> unavailable (currently the drop bundles contain the exact >>>> same files). A warning will be issued if they are used. >>>> Eventually the original jaxp/src and jaxws/src files will >>>> be deleted from the jdk7 repositories. >>>> >>>> * 'ant source' or 'cd make && make source' will get the drop >>>> bundles and populate the drop source area. But this should >>>> happen automatically. >>>> >>>> Please ask questions, this is kind of a big change and anything >>>> can go wrong, please let me know if there are problems. >>>> >>>> -kto >>>> >>>> >>> Hi Kelly, >>> >>> This patch is now in b73 and I'm trying to get IcedTea7 to build with >>> it. How do I specify the location of the zips to use? >>> >>> Thanks, >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>> >> >> I found a number of issues with the current version: >> >> * The drop zips are expected to be in a share/jdk7-drops subdirectory >> of the devtools directory. This doesn't really work outside Sun's >> internal setup. I've added support for ALT_DROP_DIR which can be used >> to specify an exact path to the zips. If this is not set, the old >> devtools behaviour is used. >> * The zips are being downloaded and extracted in the source directory, >> which could be read only. I've changed this so they are written to >> the build directory like everything else. >> >> The webrev for these changes is here: >> >> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >> >> I've committed this to IcedTea already. Does this look ok for build also? > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by Kelly O'Hair
::
Rate this Message:
I saw the webrev for a while, and now I can't :^(, but I saw enough...
>> Andrew John Hughes wrote: >>> 2009/10/7 Andrew John Hughes <gnu_andrew@...>: ...[snip]... >>> I found a number of issues with the current version: >>> >>> * The drop zips are expected to be in a share/jdk7-drops subdirectory >>> of the devtools directory. This doesn't really work outside Sun's >>> internal setup. I've added support for ALT_DROP_DIR which can be used >>> to specify an exact path to the zips. If this is not set, the old >>> devtools behaviour is used. I'm concerned about the name dropdir (your master copy location) vs. drop.dir (destination for the exploded contents) in the property names. Seems confusing. I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR and drop.bundle.dir? >>> * The zips are being downloaded and extracted in the source directory, >>> which could be read only. I've changed this so they are written to >>> the build directory like everything else. It turns out that we need this drop.dir to be in the source area if we want the openjdk source zip bundles, created by RE, to include the drop sources. These source bundles are created by bundling up everything in the forest, prior to building, so the drop.dir needs to be in the forest somehow. Otherwise, the bundling logic has to merge two separate source trees, or different roots. I was given a requirement that the openjdk source bundles include these drop sources, easiest answer was drop.dir in the repo. Not an unsurmountable problem, I avoided the more complicated path. I know that becomes an issue if the repository or source is in a read-only area, but that's not the only situation in the openjdk I suspect. I assumed someone building from a read-only area could set drop.dir to some other location. Not sure what to say. How important is it for the community that the openjdk source bundles include these drop sources? e.g. ones at http://download.java.net/openjdk/jdk7/ If they are not included, when the openjdk source bundles are built, they will need to download the jaxp and jaxws drop bundles at build time. -kto >>> >>> The webrev for these changes is here: >>> >>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>> >>> I've committed this to IcedTea already. Does this look ok for build also? > > > |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by gnu_andrew
::
Rate this Message:
2009/10/12 Kelly O'Hair <Kelly.Ohair@...>:
> I saw the webrev for a while, and now I can't :^(, but I saw enough... > >>> Andrew John Hughes wrote: >>>> >>>> 2009/10/7 Andrew John Hughes <gnu_andrew@...>: > > ...[snip]... >>>> >>>> I found a number of issues with the current version: >>>> >>>> * The drop zips are expected to be in a share/jdk7-drops subdirectory >>>> of the devtools directory. This doesn't really work outside Sun's >>>> internal setup. I've added support for ALT_DROP_DIR which can be used >>>> to specify an exact path to the zips. If this is not set, the old >>>> devtools behaviour is used. > > I'm concerned about the name dropdir (your master copy location) vs. > drop.dir > (destination for the exploded contents) in the property names. Seems > confusing. > I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR and > drop.bundle.dir? > Yes, I noticed drop.dir after posting the webrev and agree it's confusing. Would just making them ALT_DROPS_DIR and drops.dir not be sufficient? drop.bundle seems a little verbose and both mean the same thing to me at least. >>>> * The zips are being downloaded and extracted in the source directory, >>>> which could be read only. I've changed this so they are written to >>>> the build directory like everything else. > > It turns out that we need this drop.dir to be in the source area if > we want the openjdk source zip bundles, created by RE, to include > the drop sources. These source bundles are created by bundling up > everything in the forest, prior to building, so the drop.dir needs > to be in the forest somehow. Otherwise, the bundling logic has to > merge two separate source trees, or different roots. > I was given a requirement that the openjdk source bundles include these > drop sources, easiest answer was drop.dir in the repo. > Not an unsurmountable problem, I avoided the more complicated path. > > I know that becomes an issue if the repository or source is in a > read-only area, but that's not the only situation in the openjdk I suspect. > I assumed someone building from a read-only area could set > drop.dir to some other location. > Would it not make more sense for RE to set the drop.dir property into the source directory, given it's that build that's abnormal (needing to distribute a post build tree in effect)? > Not sure what to say. > > How important is it for the community that the openjdk source bundles > include these drop sources? e.g. ones at > http://download.java.net/openjdk/jdk7/ > If they are not included, when the openjdk source bundles are built, > they will need to download the jaxp and jaxws drop bundles at build time. > I obviously can't speak for everyone, but for IcedTea7 we don't even use the download bundles any more. We grab from the IcedTea forest instead, which allows patches which didn't make a bxx release to be applied there once and used in releases. We did this for the security fixes with Milestone 4/1.11. I've already added downloading of the jaxp, jaxws and jaf bundles to the IcedTea build; it's this process that resulted in this webrev. This has two advantages; we check all the zips/tarballs at the same point in the build (the JAXP and JAXWS builds are then pointed at the directory IcedTea uses for them) and we check the MD5 sums of the downloads or pre-existing zips. I don't know if the latter could be incorporated into the OpenJDK build somehow. At present, there's no guarantee that these zips are valid. The rules look like this: stamps/download-jaxp-drop.stamp: mkdir -p drops if USE_ALT_JAXP_DROP_ZIP ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) endif if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ | $(MD5SUM) --check ; \ then \ if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ then \ mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ fi ; \ $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O drops/$(JAXP_DROP_ZIP); \ fi ; mkdir -p stamps touch stamps/download-jaxp-drop.stamp ALT_JAXP_DROP_ZIP gets set if the user specifies --with-jaxp-drop-zip=<path> to configure. WGET and MD5SUM are the respective binaries as located by configure and DROP_URL is the kenai.com URL as in the jaxws.properties and jaxp.properties files: DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d > -kto > >>>> >>>> The webrev for these changes is here: >>>> >>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>> >>>> I've committed this to IcedTea already. Does this look ok for build >>>> also? >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by Kelly O'Hair
::
Rate this Message:
Andrew,
Sorry I'm so slow on this, ... I'm looking at updating the jaxp bundle. The webrev is: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-6861589/webrev/ Updated jaxp source bundle, and complete removal of anything that would use the original source. The final changeset will also delete the jaxp/src directory so we never accidently use it. It also adds a md5 checksum check on the bundle in the ant script, a property value contains the expected checksum. I'm not done, so I could add more if you want me to add the changes mentioned here... The merge should be trivial. One snag is that I plan on pushing this to the TL forest so that the TL integrator (Tim Bell) can get the appropriate tests done on the jaxp changes. In the future jaxp changes will probably be going through the TL area. ... a few more comments below... Andrew John Hughes wrote: > 2009/10/12 Kelly O'Hair <Kelly.Ohair@...>: >> I saw the webrev for a while, and now I can't :^(, but I saw enough... >> >>>> Andrew John Hughes wrote: >>>>> 2009/10/7 Andrew John Hughes <gnu_andrew@...>: >> ...[snip]... >>>>> I found a number of issues with the current version: >>>>> >>>>> * The drop zips are expected to be in a share/jdk7-drops subdirectory >>>>> of the devtools directory. This doesn't really work outside Sun's >>>>> internal setup. I've added support for ALT_DROP_DIR which can be used >>>>> to specify an exact path to the zips. If this is not set, the old >>>>> devtools behaviour is used. >> I'm concerned about the name dropdir (your master copy location) vs. >> drop.dir >> (destination for the exploded contents) in the property names. Seems >> confusing. >> I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR and >> drop.bundle.dir? >> > > Yes, I noticed drop.dir after posting the webrev and agree it's > confusing. Would just making them ALT_DROPS_DIR and drops.dir not be > sufficient? drop.bundle seems a little verbose and both mean the same > thing to me at least. I'm ok with ALT_DROPS_DIR and drops.dir. > >>>>> * The zips are being downloaded and extracted in the source directory, >>>>> which could be read only. I've changed this so they are written to >>>>> the build directory like everything else. >> It turns out that we need this drop.dir to be in the source area if >> we want the openjdk source zip bundles, created by RE, to include >> the drop sources. These source bundles are created by bundling up >> everything in the forest, prior to building, so the drop.dir needs >> to be in the forest somehow. Otherwise, the bundling logic has to >> merge two separate source trees, or different roots. >> I was given a requirement that the openjdk source bundles include these >> drop sources, easiest answer was drop.dir in the repo. >> Not an unsurmountable problem, I avoided the more complicated path. >> >> I know that becomes an issue if the repository or source is in a >> read-only area, but that's not the only situation in the openjdk I suspect. >> I assumed someone building from a read-only area could set >> drop.dir to some other location. >> > > Would it not make more sense for RE to set the drop.dir property into > the source directory, given it's that build that's abnormal (needing > to distribute a post build tree in effect)? I will look into that. You have convinced me. ;^) > >> Not sure what to say. >> >> How important is it for the community that the openjdk source bundles >> include these drop sources? e.g. ones at >> http://download.java.net/openjdk/jdk7/ >> If they are not included, when the openjdk source bundles are built, >> they will need to download the jaxp and jaxws drop bundles at build time. >> > > I obviously can't speak for everyone, but for IcedTea7 we don't even > use the download bundles any more. We grab from the IcedTea forest > instead, which allows patches which didn't make a bxx release to be > applied there once and used in releases. We did this for the security > fixes with Milestone 4/1.11. > > I've already added downloading of the jaxp, jaxws and jaf bundles to > the IcedTea build; it's this process that resulted in this webrev. > This has two advantages; we check all the zips/tarballs at the same > point in the build (the JAXP and JAXWS builds are then pointed at the > directory IcedTea uses for them) and we check the MD5 sums of the > downloads or pre-existing zips. I don't know if the latter could be > incorporated into the OpenJDK build somehow. At present, there's no > guarantee that these zips are valid. > > The rules look like this: > > stamps/download-jaxp-drop.stamp: > mkdir -p drops > if USE_ALT_JAXP_DROP_ZIP > ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) > endif > if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ > | $(MD5SUM) --check ; \ > then \ > if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ > then \ > mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ > fi ; \ > $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O > drops/$(JAXP_DROP_ZIP); \ > fi ; > mkdir -p stamps > touch stamps/download-jaxp-drop.stamp > > ALT_JAXP_DROP_ZIP gets set if the user specifies > --with-jaxp-drop-zip=<path> to configure. WGET and MD5SUM are the > respective binaries as located by configure and DROP_URL is the > kenai.com URL as in the jaxws.properties and jaxp.properties files: > > DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download > JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip > JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 > JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip > JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 > JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip > JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d Ah... so my checksum logic in the ant script will serve as a double check. Unless you are changing the bundles and rebundling them... nobody does that, ... do they??? Ah, if they do, they would need to change the property value holding the checksum. -kto > >> -kto >> >>>>> The webrev for these changes is here: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>>> >>>>> I've committed this to IcedTea already. Does this look ok for build >>>>> also? >>> >>> > > > |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by Kelly O'Hair
::
Rate this Message:
Sigh... if I'm changing jaxp, might as well change jaxws too.... keep them in sync. I effectively included the drop.dir change you wanted with these webrevs: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp/webrev/ http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws/webrev/ In both cases, any use of the original source is being removed, and the changeset I create will probably just delete the "src/" directory. I'm using a different directory name when the dropped sources are baked in by our RE people, "drop_included" (should have called these batteries so I could use "batteries_included". ;^) So there are two properties drop.expanded.dir and drop.included.dir, and the drop.dir property is conditional set in the ant script. But I did not add the ALT_DROPS_DIR change. Do you want me to include that, or do you want to make that change separately? -kto |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by jonathan.gibbons
::
Rate this Message:
Kelly O'Hair wrote:
> Andrew, > > Sorry I'm so slow on this, ... > > I'm looking at updating the jaxp bundle. The webrev is: > > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-6861589/webrev/ > > Updated jaxp source bundle, and complete removal of anything > that would use the original source. The final changeset will also > delete the jaxp/src directory so we never accidently use it. > It also adds a md5 checksum check on the bundle in the ant script, > a property value contains the expected checksum. > > I'm not done, so I could add more if you want me to add the changes > mentioned here... The merge should be trivial. > > One snag is that I plan on pushing this to the TL forest so that > the TL integrator (Tim Bell) can get the appropriate tests done > on the jaxp changes. In the future jaxp changes will probably > be going through the TL area. > > ... a few more comments below... > > Andrew John Hughes wrote: >> 2009/10/12 Kelly O'Hair <Kelly.Ohair@...>: >>> I saw the webrev for a while, and now I can't :^(, but I saw enough... >>> >>>>> Andrew John Hughes wrote: >>>>>> 2009/10/7 Andrew John Hughes <gnu_andrew@...>: >>> ...[snip]... >>>>>> I found a number of issues with the current version: >>>>>> >>>>>> * The drop zips are expected to be in a share/jdk7-drops >>>>>> subdirectory >>>>>> of the devtools directory. This doesn't really work outside Sun's >>>>>> internal setup. I've added support for ALT_DROP_DIR which can be >>>>>> used >>>>>> to specify an exact path to the zips. If this is not set, the old >>>>>> devtools behaviour is used. >>> I'm concerned about the name dropdir (your master copy location) vs. >>> drop.dir >>> (destination for the exploded contents) in the property names. Seems >>> confusing. >>> I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR and >>> drop.bundle.dir? >>> >> >> Yes, I noticed drop.dir after posting the webrev and agree it's >> confusing. Would just making them ALT_DROPS_DIR and drops.dir not be >> sufficient? drop.bundle seems a little verbose and both mean the same >> thing to me at least. > > I'm ok with ALT_DROPS_DIR and drops.dir. > >> >>>>>> * The zips are being downloaded and extracted in the source >>>>>> directory, >>>>>> which could be read only. I've changed this so they are written to >>>>>> the build directory like everything else. >>> It turns out that we need this drop.dir to be in the source area if >>> we want the openjdk source zip bundles, created by RE, to include >>> the drop sources. These source bundles are created by bundling up >>> everything in the forest, prior to building, so the drop.dir needs >>> to be in the forest somehow. Otherwise, the bundling logic has to >>> merge two separate source trees, or different roots. >>> I was given a requirement that the openjdk source bundles include these >>> drop sources, easiest answer was drop.dir in the repo. >>> Not an unsurmountable problem, I avoided the more complicated path. >>> >>> I know that becomes an issue if the repository or source is in a >>> read-only area, but that's not the only situation in the openjdk I >>> suspect. >>> I assumed someone building from a read-only area could set >>> drop.dir to some other location. >>> >> >> Would it not make more sense for RE to set the drop.dir property into >> the source directory, given it's that build that's abnormal (needing >> to distribute a post build tree in effect)? > > I will look into that. You have convinced me. ;^) > >> >>> Not sure what to say. >>> >>> How important is it for the community that the openjdk source bundles >>> include these drop sources? e.g. ones at >>> http://download.java.net/openjdk/jdk7/ >>> If they are not included, when the openjdk source bundles are built, >>> they will need to download the jaxp and jaxws drop bundles at build >>> time. >>> >> >> I obviously can't speak for everyone, but for IcedTea7 we don't even >> use the download bundles any more. We grab from the IcedTea forest >> instead, which allows patches which didn't make a bxx release to be >> applied there once and used in releases. We did this for the security >> fixes with Milestone 4/1.11. >> >> I've already added downloading of the jaxp, jaxws and jaf bundles to >> the IcedTea build; it's this process that resulted in this webrev. >> This has two advantages; we check all the zips/tarballs at the same >> point in the build (the JAXP and JAXWS builds are then pointed at the >> directory IcedTea uses for them) and we check the MD5 sums of the >> downloads or pre-existing zips. I don't know if the latter could be >> incorporated into the OpenJDK build somehow. At present, there's no >> guarantee that these zips are valid. >> >> The rules look like this: >> >> stamps/download-jaxp-drop.stamp: >> mkdir -p drops >> if USE_ALT_JAXP_DROP_ZIP >> ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) >> endif >> if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ >> | $(MD5SUM) --check ; \ >> then \ >> if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ >> then \ >> mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ >> fi ; \ >> $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O >> drops/$(JAXP_DROP_ZIP); \ >> fi ; >> mkdir -p stamps >> touch stamps/download-jaxp-drop.stamp >> >> ALT_JAXP_DROP_ZIP gets set if the user specifies >> --with-jaxp-drop-zip=<path> to configure. WGET and MD5SUM are the >> respective binaries as located by configure and DROP_URL is the >> kenai.com URL as in the jaxws.properties and jaxp.properties files: >> >> DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download >> JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip >> JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 >> JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip >> JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 >> JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip >> JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d > > Ah... so my checksum logic in the ant script will serve as a > double check. > > Unless you are changing the bundles and rebundling them... > nobody does that, ... do they??? > Ah, if they do, they would need to change the property value > holding the checksum. > > -kto > >> >>> -kto >>> >>>>>> The webrev for these changes is here: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>>>> >>>>>> I've committed this to IcedTea already. Does this look ok for build >>>>>> also? >>>> >>>> >> >> >> Does all this mean we can somewhat simplify the list of forests on hg.o.j.n, by removing jdk7/{corba,jaxp,jaxws} and the corresponding -gate forests? -- Jon |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by gnu_andrew
::
Rate this Message:
2009/10/23 Kelly O'Hair <Kelly.Ohair@...>:
> > Sigh... if I'm changing jaxp, might as well change jaxws too.... > keep them in sync. > > I effectively included the drop.dir change you wanted with these > webrevs: > > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp/webrev/ > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws/webrev/ > > In both cases, any use of the original source is being removed, and > the changeset I create will probably just delete the "src/" directory. > Good, makes things clearer. > I'm using a different directory name when the dropped sources are > baked in by our RE people, "drop_included" (should have called these > batteries so I could use "batteries_included". ;^) > Ok, I think it makes the build.xml more complicated than necessary, given you could just set drop.dir for builds which include the source, but I'm happy enough with it. > So there are two properties drop.expanded.dir and drop.included.dir, > and the drop.dir property is conditional set in the ant script. > > But I did not add the ALT_DROPS_DIR change. > Do you want me to include that, or do you want to make that change > separately? > There's already three changes in this one changeset: * Removing the original source option * Adding drop.expanded (which seems similar to the original source option except you can specify the directory) * Checksumming so I'd rather we had the ALT_DROPS_DIR in a separate one, but I don't mind who commits it. I also notice the URL changes -- why? > -kto > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by Kelly O'Hair
::
Rate this Message:
Jonathan Gibbons wrote: > Kelly O'Hair wrote: >> Andrew, >> >> Sorry I'm so slow on this, ... >> >> I'm looking at updating the jaxp bundle. The webrev is: >> >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-6861589/webrev/ >> >> Updated jaxp source bundle, and complete removal of anything >> that would use the original source. The final changeset will also >> delete the jaxp/src directory so we never accidently use it. >> It also adds a md5 checksum check on the bundle in the ant script, >> a property value contains the expected checksum. >> >> I'm not done, so I could add more if you want me to add the changes >> mentioned here... The merge should be trivial. >> >> One snag is that I plan on pushing this to the TL forest so that >> the TL integrator (Tim Bell) can get the appropriate tests done >> on the jaxp changes. In the future jaxp changes will probably >> be going through the TL area. >> >> ... a few more comments below... >> >> Andrew John Hughes wrote: >>> 2009/10/12 Kelly O'Hair <Kelly.Ohair@...>: >>>> I saw the webrev for a while, and now I can't :^(, but I saw enough... >>>> >>>>>> Andrew John Hughes wrote: >>>>>>> 2009/10/7 Andrew John Hughes <gnu_andrew@...>: >>>> ...[snip]... >>>>>>> I found a number of issues with the current version: >>>>>>> >>>>>>> * The drop zips are expected to be in a share/jdk7-drops >>>>>>> subdirectory >>>>>>> of the devtools directory. This doesn't really work outside Sun's >>>>>>> internal setup. I've added support for ALT_DROP_DIR which can be >>>>>>> used >>>>>>> to specify an exact path to the zips. If this is not set, the old >>>>>>> devtools behaviour is used. >>>> I'm concerned about the name dropdir (your master copy location) vs. >>>> drop.dir >>>> (destination for the exploded contents) in the property names. Seems >>>> confusing. >>>> I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR and >>>> drop.bundle.dir? >>>> >>> >>> Yes, I noticed drop.dir after posting the webrev and agree it's >>> confusing. Would just making them ALT_DROPS_DIR and drops.dir not be >>> sufficient? drop.bundle seems a little verbose and both mean the same >>> thing to me at least. >> >> I'm ok with ALT_DROPS_DIR and drops.dir. >> >>> >>>>>>> * The zips are being downloaded and extracted in the source >>>>>>> directory, >>>>>>> which could be read only. I've changed this so they are written to >>>>>>> the build directory like everything else. >>>> It turns out that we need this drop.dir to be in the source area if >>>> we want the openjdk source zip bundles, created by RE, to include >>>> the drop sources. These source bundles are created by bundling up >>>> everything in the forest, prior to building, so the drop.dir needs >>>> to be in the forest somehow. Otherwise, the bundling logic has to >>>> merge two separate source trees, or different roots. >>>> I was given a requirement that the openjdk source bundles include these >>>> drop sources, easiest answer was drop.dir in the repo. >>>> Not an unsurmountable problem, I avoided the more complicated path. >>>> >>>> I know that becomes an issue if the repository or source is in a >>>> read-only area, but that's not the only situation in the openjdk I >>>> suspect. >>>> I assumed someone building from a read-only area could set >>>> drop.dir to some other location. >>>> >>> >>> Would it not make more sense for RE to set the drop.dir property into >>> the source directory, given it's that build that's abnormal (needing >>> to distribute a post build tree in effect)? >> >> I will look into that. You have convinced me. ;^) >> >>> >>>> Not sure what to say. >>>> >>>> How important is it for the community that the openjdk source bundles >>>> include these drop sources? e.g. ones at >>>> http://download.java.net/openjdk/jdk7/ >>>> If they are not included, when the openjdk source bundles are built, >>>> they will need to download the jaxp and jaxws drop bundles at build >>>> time. >>>> >>> >>> I obviously can't speak for everyone, but for IcedTea7 we don't even >>> use the download bundles any more. We grab from the IcedTea forest >>> instead, which allows patches which didn't make a bxx release to be >>> applied there once and used in releases. We did this for the security >>> fixes with Milestone 4/1.11. >>> >>> I've already added downloading of the jaxp, jaxws and jaf bundles to >>> the IcedTea build; it's this process that resulted in this webrev. >>> This has two advantages; we check all the zips/tarballs at the same >>> point in the build (the JAXP and JAXWS builds are then pointed at the >>> directory IcedTea uses for them) and we check the MD5 sums of the >>> downloads or pre-existing zips. I don't know if the latter could be >>> incorporated into the OpenJDK build somehow. At present, there's no >>> guarantee that these zips are valid. >>> >>> The rules look like this: >>> >>> stamps/download-jaxp-drop.stamp: >>> mkdir -p drops >>> if USE_ALT_JAXP_DROP_ZIP >>> ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) >>> endif >>> if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ >>> | $(MD5SUM) --check ; \ >>> then \ >>> if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ >>> then \ >>> mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ >>> fi ; \ >>> $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O >>> drops/$(JAXP_DROP_ZIP); \ >>> fi ; >>> mkdir -p stamps >>> touch stamps/download-jaxp-drop.stamp >>> >>> ALT_JAXP_DROP_ZIP gets set if the user specifies >>> --with-jaxp-drop-zip=<path> to configure. WGET and MD5SUM are the >>> respective binaries as located by configure and DROP_URL is the >>> kenai.com URL as in the jaxws.properties and jaxp.properties files: >>> >>> DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download >>> JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip >>> JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 >>> JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip >>> JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 >>> JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip >>> JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d >> >> Ah... so my checksum logic in the ant script will serve as a >> double check. >> >> Unless you are changing the bundles and rebundling them... >> nobody does that, ... do they??? >> Ah, if they do, they would need to change the property value >> holding the checksum. >> >> -kto >> >>> >>>> -kto >>>> >>>>>>> The webrev for these changes is here: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>>>>> >>>>>>> I've committed this to IcedTea already. Does this look ok for build >>>>>>> also? >>>>> >>>>> >>> >>> >>> > Kelly, > > Does all this mean we can somewhat simplify the list of forests on > hg.o.j.n, by removing jdk7/{corba,jaxp,jaxws} and the corresponding > -gate forests? > > -- Jon No. Not yet. In theory, what little logic is left in jaxp and jaxws (corba has not changed), could be folded up into the top repo or the jdk repo, and you could empty out jaxp and jaxws repos entirely. But I had no plans to do so. What this does is leave a small set of ant scripts and a Makefile over it, in these repos. The build logic is about all that is there, and it will get the jaxp or jaxws source bundle drops, and build them. This change will delete the original sources from the repo, to guarantee they are no longer used. The detailed management of those sources is completely under the control of the jaxp and jaxws teams/projects. The selection of which drop bundles the jdk7 project uses is defined in the jaxp/jaxp.properties and jaxws/jaxws.properties files. -kto |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by jonathan.gibbons
::
Rate this Message:
Kelly O'Hair wrote:
Kelly, I was not referring to the jaxp/jaxws/corba repositories in each forest. It seemed like we had (mostly unused) forests for integrating jaxp,jaxws,corba stuff. Specifically: |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by Kelly O'Hair
::
Rate this Message:
Andrew John Hughes wrote: > 2009/10/23 Kelly O'Hair <Kelly.Ohair@...>: >> Sigh... if I'm changing jaxp, might as well change jaxws too.... >> keep them in sync. >> >> I effectively included the drop.dir change you wanted with these >> webrevs: >> >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp/webrev/ >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws/webrev/ >> >> In both cases, any use of the original source is being removed, and >> the changeset I create will probably just delete the "src/" directory. >> > > Good, makes things clearer. > >> I'm using a different directory name when the dropped sources are >> baked in by our RE people, "drop_included" (should have called these >> batteries so I could use "batteries_included". ;^) >> > > Ok, I think it makes the build.xml more complicated than necessary, > given you could just set drop.dir for builds which include the source, > but I'm happy enough with it. There are problems with building from the source bundles that included the drop sources. I need to protect the drop_included sources from being deleted with an 'ant clobber' or 'make clobber'. Putting them in separately named directory was obvious, but what wasn't obvious was how to make that a permanent and protected source area when building with a source bundle. Baking in the idea of a drop_included directory was the only way to protect drop_included from being deleted accidently, and also make it the higher priority source location, when it exists, the drop bundles and drop area should not be needed. > >> So there are two properties drop.expanded.dir and drop.included.dir, >> and the drop.dir property is conditional set in the ant script. >> >> But I did not add the ALT_DROPS_DIR change. >> Do you want me to include that, or do you want to make that change >> separately? >> > > There's already three changes in this one changeset: > > * Removing the original source option > * Adding drop.expanded (which seems similar to the original source > option except you can specify the directory) > * Checksumming > > so I'd rather we had the ALT_DROPS_DIR in a separate one, but I don't > mind who commits it. OK. I'll hold off on the ALT_DROPS_DIR. > > I also notice the URL changes -- why? The jaxp source bundle is being updated. The kenai.com urls were mine, and somewhat temporary. The jaxp/jaxws teams get to pick where these bundles will live. With java.net, I think adding a new file creates a new url. :^( So I suspect, every bundle update may create a new url, but I just use what they give me. I'll try and separate these changes into different changesets, but will need to file separate bugs. -kto > >> -kto >> > > Thanks, |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by Kelly O'Hair
::
Rate this Message:
Jonathan Gibbons wrote: > Kelly O'Hair wrote: >> >> >> Jonathan Gibbons wrote: >>> Kelly O'Hair wrote: >>>> Andrew, >>>> >>>> Sorry I'm so slow on this, ... >>>> >>>> I'm looking at updating the jaxp bundle. The webrev is: >>>> >>>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-6861589/webrev/ >>>> >>>> Updated jaxp source bundle, and complete removal of anything >>>> that would use the original source. The final changeset will also >>>> delete the jaxp/src directory so we never accidently use it. >>>> It also adds a md5 checksum check on the bundle in the ant script, >>>> a property value contains the expected checksum. >>>> >>>> I'm not done, so I could add more if you want me to add the changes >>>> mentioned here... The merge should be trivial. >>>> >>>> One snag is that I plan on pushing this to the TL forest so that >>>> the TL integrator (Tim Bell) can get the appropriate tests done >>>> on the jaxp changes. In the future jaxp changes will probably >>>> be going through the TL area. >>>> >>>> ... a few more comments below... >>>> >>>> Andrew John Hughes wrote: >>>>> 2009/10/12 Kelly O'Hair <Kelly.Ohair@...>: >>>>>> I saw the webrev for a while, and now I can't :^(, but I saw >>>>>> enough... >>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>>> 2009/10/7 Andrew John Hughes <gnu_andrew@...>: >>>>>> ...[snip]... >>>>>>>>> I found a number of issues with the current version: >>>>>>>>> >>>>>>>>> * The drop zips are expected to be in a share/jdk7-drops >>>>>>>>> subdirectory >>>>>>>>> of the devtools directory. This doesn't really work outside Sun's >>>>>>>>> internal setup. I've added support for ALT_DROP_DIR which can >>>>>>>>> be used >>>>>>>>> to specify an exact path to the zips. If this is not set, the old >>>>>>>>> devtools behaviour is used. >>>>>> I'm concerned about the name dropdir (your master copy location) vs. >>>>>> drop.dir >>>>>> (destination for the exploded contents) in the property names. Seems >>>>>> confusing. >>>>>> I hesitate to go on a name hunt, but what about >>>>>> ALT_DROP_BUNDLE_DIR and >>>>>> drop.bundle.dir? >>>>>> >>>>> >>>>> Yes, I noticed drop.dir after posting the webrev and agree it's >>>>> confusing. Would just making them ALT_DROPS_DIR and drops.dir not be >>>>> sufficient? drop.bundle seems a little verbose and both mean the same >>>>> thing to me at least. >>>> >>>> I'm ok with ALT_DROPS_DIR and drops.dir. >>>> >>>>> >>>>>>>>> * The zips are being downloaded and extracted in the source >>>>>>>>> directory, >>>>>>>>> which could be read only. I've changed this so they are >>>>>>>>> written to >>>>>>>>> the build directory like everything else. >>>>>> It turns out that we need this drop.dir to be in the source area if >>>>>> we want the openjdk source zip bundles, created by RE, to include >>>>>> the drop sources. These source bundles are created by bundling up >>>>>> everything in the forest, prior to building, so the drop.dir needs >>>>>> to be in the forest somehow. Otherwise, the bundling logic has to >>>>>> merge two separate source trees, or different roots. >>>>>> I was given a requirement that the openjdk source bundles include >>>>>> these >>>>>> drop sources, easiest answer was drop.dir in the repo. >>>>>> Not an unsurmountable problem, I avoided the more complicated path. >>>>>> >>>>>> I know that becomes an issue if the repository or source is in a >>>>>> read-only area, but that's not the only situation in the openjdk I >>>>>> suspect. >>>>>> I assumed someone building from a read-only area could set >>>>>> drop.dir to some other location. >>>>>> >>>>> >>>>> Would it not make more sense for RE to set the drop.dir property into >>>>> the source directory, given it's that build that's abnormal (needing >>>>> to distribute a post build tree in effect)? >>>> >>>> I will look into that. You have convinced me. ;^) >>>> >>>>> >>>>>> Not sure what to say. >>>>>> >>>>>> How important is it for the community that the openjdk source bundles >>>>>> include these drop sources? e.g. ones at >>>>>> http://download.java.net/openjdk/jdk7/ >>>>>> If they are not included, when the openjdk source bundles are built, >>>>>> they will need to download the jaxp and jaxws drop bundles at >>>>>> build time. >>>>>> >>>>> >>>>> I obviously can't speak for everyone, but for IcedTea7 we don't even >>>>> use the download bundles any more. We grab from the IcedTea forest >>>>> instead, which allows patches which didn't make a bxx release to be >>>>> applied there once and used in releases. We did this for the security >>>>> fixes with Milestone 4/1.11. >>>>> >>>>> I've already added downloading of the jaxp, jaxws and jaf bundles to >>>>> the IcedTea build; it's this process that resulted in this webrev. >>>>> This has two advantages; we check all the zips/tarballs at the same >>>>> point in the build (the JAXP and JAXWS builds are then pointed at the >>>>> directory IcedTea uses for them) and we check the MD5 sums of the >>>>> downloads or pre-existing zips. I don't know if the latter could be >>>>> incorporated into the OpenJDK build somehow. At present, there's no >>>>> guarantee that these zips are valid. >>>>> >>>>> The rules look like this: >>>>> >>>>> stamps/download-jaxp-drop.stamp: >>>>> mkdir -p drops >>>>> if USE_ALT_JAXP_DROP_ZIP >>>>> ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) >>>>> endif >>>>> if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ >>>>> | $(MD5SUM) --check ; \ >>>>> then \ >>>>> if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ >>>>> then \ >>>>> mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ >>>>> fi ; \ >>>>> $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O >>>>> drops/$(JAXP_DROP_ZIP); \ >>>>> fi ; >>>>> mkdir -p stamps >>>>> touch stamps/download-jaxp-drop.stamp >>>>> >>>>> ALT_JAXP_DROP_ZIP gets set if the user specifies >>>>> --with-jaxp-drop-zip=<path> to configure. WGET and MD5SUM are the >>>>> respective binaries as located by configure and DROP_URL is the >>>>> kenai.com URL as in the jaxws.properties and jaxp.properties files: >>>>> >>>>> DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download >>>>> JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip >>>>> JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 >>>>> JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip >>>>> JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 >>>>> JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip >>>>> JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d >>>> >>>> Ah... so my checksum logic in the ant script will serve as a >>>> double check. >>>> >>>> Unless you are changing the bundles and rebundling them... >>>> nobody does that, ... do they??? >>>> Ah, if they do, they would need to change the property value >>>> holding the checksum. >>>> >>>> -kto >>>> >>>>> >>>>>> -kto >>>>>> >>>>>>>>> The webrev for these changes is here: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>>>>>>> >>>>>>>>> I've committed this to IcedTea already. Does this look ok for >>>>>>>>> build >>>>>>>>> also? >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> Kelly, >>> >>> Does all this mean we can somewhat simplify the list of forests on >>> hg.o.j.n, by removing jdk7/{corba,jaxp,jaxws} and the corresponding >>> -gate forests? >>> >>> -- Jon >> >> No. Not yet. In theory, what little logic is left in jaxp and jaxws >> (corba has not changed), could be folded up into the top repo >> or the jdk repo, and you could empty out jaxp and jaxws repos >> entirely. But I had no plans to do so. >> >> What this does is leave a small set of ant scripts and a >> Makefile over it, in these repos. The build logic is about all >> that is there, and it will get the jaxp or jaxws source bundle drops, >> and build them. This change will delete the original sources from >> the repo, to guarantee they are no longer used. >> The detailed management of those sources is completely under >> the control of the jaxp and jaxws teams/projects. >> >> The selection of which drop bundles the jdk7 project uses is defined in >> the jaxp/jaxp.properties and jaxws/jaxws.properties files. >> >> -kto > Kelly, > > I was not referring to the jaxp/jaxws/corba repositories in each > forest. It seemed like we had (mostly unused) forests for integrating > jaxp,jaxws,corba stuff. Specifically: > > > *jdk7/jaxp* <http://hg.openjdk.java.net/jdk7/jaxp/> jaxp > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxp/archive/tip.tar.bz2> > *jdk7/jaxp-gate* <http://hg.openjdk.java.net/jdk7/jaxp-gate/> jaxp > (gate) build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp-gate/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp-gate/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp-gate/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxp-gate/archive/tip.tar.bz2> > *jdk7/jaxp-gate/corba* > <http://hg.openjdk.java.net/jdk7/jaxp-gate/corba/> jaxp (gate) > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp-gate/corba/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp-gate/corba/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp-gate/corba/archive/tip.tar.gz> | > bz2 <http://hg.openjdk.java.net/jdk7/jaxp-gate/corba/archive/tip.tar.bz2> > *jdk7/jaxp-gate/hotspot* > <http://hg.openjdk.java.net/jdk7/jaxp-gate/hotspot/> jaxp (gate) > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp-gate/hotspot/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp-gate/hotspot/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp-gate/hotspot/archive/tip.tar.gz> | > bz2 <http://hg.openjdk.java.net/jdk7/jaxp-gate/hotspot/archive/tip.tar.bz2> > *jdk7/jaxp-gate/jaxp* > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxp/> jaxp (gate) > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxp/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxp/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxp/archive/tip.tar.gz> | > bz2 <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxp/archive/tip.tar.bz2> > *jdk7/jaxp-gate/jaxws* > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxws/> jaxp (gate) > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxws/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxws/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxws/archive/tip.tar.gz> | > bz2 <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxws/archive/tip.tar.bz2> > *jdk7/jaxp-gate/jdk* <http://hg.openjdk.java.net/jdk7/jaxp-gate/jdk/> > jaxp (gate) build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jdk/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jdk/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jdk/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxp-gate/jdk/archive/tip.tar.bz2> > *jdk7/jaxp-gate/langtools* > <http://hg.openjdk.java.net/jdk7/jaxp-gate/langtools/> jaxp (gate) > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp-gate/langtools/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp-gate/langtools/archive/tip.zip> | > gz > <http://hg.openjdk.java.net/jdk7/jaxp-gate/langtools/archive/tip.tar.gz> > | bz2 > <http://hg.openjdk.java.net/jdk7/jaxp-gate/langtools/archive/tip.tar.bz2> > *jdk7/jaxp/corba* <http://hg.openjdk.java.net/jdk7/jaxp/corba/> jaxp > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp/corba/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp/corba/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp/corba/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxp/corba/archive/tip.tar.bz2> > *jdk7/jaxp/hotspot* <http://hg.openjdk.java.net/jdk7/jaxp/hotspot/> > jaxp build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp/hotspot/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp/hotspot/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp/hotspot/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxp/hotspot/archive/tip.tar.bz2> > *jdk7/jaxp/jaxp* <http://hg.openjdk.java.net/jdk7/jaxp/jaxp/> jaxp > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp/jaxp/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp/jaxp/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp/jaxp/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxp/jaxp/archive/tip.tar.bz2> > *jdk7/jaxp/jaxws* <http://hg.openjdk.java.net/jdk7/jaxp/jaxws/> jaxp > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp/jaxws/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp/jaxws/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp/jaxws/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxp/jaxws/archive/tip.tar.bz2> > *jdk7/jaxp/jdk* <http://hg.openjdk.java.net/jdk7/jaxp/jdk/> jaxp > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp/jdk/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp/jdk/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp/jdk/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxp/jdk/archive/tip.tar.bz2> > *jdk7/jaxp/langtools* > <http://hg.openjdk.java.net/jdk7/jaxp/langtools/> jaxp > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxp/langtools/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxp/langtools/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxp/langtools/archive/tip.tar.gz> | > bz2 <http://hg.openjdk.java.net/jdk7/jaxp/langtools/archive/tip.tar.bz2> > *jdk7/jaxws* <http://hg.openjdk.java.net/jdk7/jaxws/> jaxws > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxws/archive/tip.tar.bz2> > *jdk7/jaxws-gate* <http://hg.openjdk.java.net/jdk7/jaxws-gate/> jaxws > (gate) build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws-gate/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws-gate/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws-gate/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxws-gate/archive/tip.tar.bz2> > *jdk7/jaxws-gate/corba* > <http://hg.openjdk.java.net/jdk7/jaxws-gate/corba/> jaxws (gate) > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws-gate/corba/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws-gate/corba/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws-gate/corba/archive/tip.tar.gz> | > bz2 <http://hg.openjdk.java.net/jdk7/jaxws-gate/corba/archive/tip.tar.bz2> > *jdk7/jaxws-gate/hotspot* > <http://hg.openjdk.java.net/jdk7/jaxws-gate/hotspot/> jaxws (gate) > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws-gate/hotspot/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws-gate/hotspot/archive/tip.zip> | > gz > <http://hg.openjdk.java.net/jdk7/jaxws-gate/hotspot/archive/tip.tar.gz> > | bz2 > <http://hg.openjdk.java.net/jdk7/jaxws-gate/hotspot/archive/tip.tar.bz2> > *jdk7/jaxws-gate/jaxp* > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxp/> jaxws (gate) > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxp/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxp/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxp/archive/tip.tar.gz> | > bz2 <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxp/archive/tip.tar.bz2> > *jdk7/jaxws-gate/jaxws* > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxws/> jaxws (gate) > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxws/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxws/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxws/archive/tip.tar.gz> | > bz2 <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxws/archive/tip.tar.bz2> > *jdk7/jaxws-gate/jdk* > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jdk/> jaxws (gate) > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jdk/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jdk/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws-gate/jdk/archive/tip.tar.gz> | > bz2 <http://hg.openjdk.java.net/jdk7/jaxws-gate/jdk/archive/tip.tar.bz2> > *jdk7/jaxws-gate/langtools* > <http://hg.openjdk.java.net/jdk7/jaxws-gate/langtools/> jaxws (gate) > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws-gate/langtools/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws-gate/langtools/archive/tip.zip> | > gz > <http://hg.openjdk.java.net/jdk7/jaxws-gate/langtools/archive/tip.tar.gz> > | bz2 > <http://hg.openjdk.java.net/jdk7/jaxws-gate/langtools/archive/tip.tar.bz2> > *jdk7/jaxws/corba* <http://hg.openjdk.java.net/jdk7/jaxws/corba/> > jaxws build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws/corba/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws/corba/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws/corba/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxws/corba/archive/tip.tar.bz2> > *jdk7/jaxws/hotspot* <http://hg.openjdk.java.net/jdk7/jaxws/hotspot/> > jaxws build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws/hotspot/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws/hotspot/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws/hotspot/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxws/hotspot/archive/tip.tar.bz2> > *jdk7/jaxws/jaxp* <http://hg.openjdk.java.net/jdk7/jaxws/jaxp/> jaxws > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws/jaxp/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws/jaxp/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws/jaxp/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxws/jaxp/archive/tip.tar.bz2> > *jdk7/jaxws/jaxws* <http://hg.openjdk.java.net/jdk7/jaxws/jaxws/> > jaxws build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws/jaxws/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws/jaxws/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws/jaxws/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxws/jaxws/archive/tip.tar.bz2> > *jdk7/jaxws/jdk* <http://hg.openjdk.java.net/jdk7/jaxws/jdk/> jaxws > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws/jdk/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws/jdk/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws/jdk/archive/tip.tar.gz> | bz2 > <http://hg.openjdk.java.net/jdk7/jaxws/jdk/archive/tip.tar.bz2> > *jdk7/jaxws/langtools* > <http://hg.openjdk.java.net/jdk7/jaxws/langtools/> jaxws > build-dev@... 20 months ago RSS > <http://hg.openjdk.java.net/jdk7/jaxws/langtools/rss-log> | zip > <http://hg.openjdk.java.net/jdk7/jaxws/langtools/archive/tip.zip> | gz > <http://hg.openjdk.java.net/jdk7/jaxws/langtools/archive/tip.tar.gz> | > bz2 <http://hg.openjdk.java.net/jdk7/jaxws/langtools/archive/tip.tar.bz2> > > > DOH! Sorry... Yes, these jaxp and jaxws forests can probably go away, we won't be using them. The current plan is that jaxp/jaxws changes (new bundles) will go through the TL forest. -kto |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by gnu_andrew
::
Rate this Message:
2009/10/23 Kelly O'Hair <Kelly.Ohair@...>:
> > > Jonathan Gibbons wrote: >> >> Kelly O'Hair wrote: >>> >>> >>> Jonathan Gibbons wrote: >>>> >>>> Kelly O'Hair wrote: >>>>> >>>>> Andrew, >>>>> >>>>> Sorry I'm so slow on this, ... >>>>> >>>>> I'm looking at updating the jaxp bundle. The webrev is: >>>>> >>>>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-6861589/webrev/ >>>>> >>>>> Updated jaxp source bundle, and complete removal of anything >>>>> that would use the original source. The final changeset will also >>>>> delete the jaxp/src directory so we never accidently use it. >>>>> It also adds a md5 checksum check on the bundle in the ant script, >>>>> a property value contains the expected checksum. >>>>> >>>>> I'm not done, so I could add more if you want me to add the changes >>>>> mentioned here... The merge should be trivial. >>>>> >>>>> One snag is that I plan on pushing this to the TL forest so that >>>>> the TL integrator (Tim Bell) can get the appropriate tests done >>>>> on the jaxp changes. In the future jaxp changes will probably >>>>> be going through the TL area. >>>>> >>>>> ... a few more comments below... >>>>> >>>>> Andrew John Hughes wrote: >>>>>> >>>>>> 2009/10/12 Kelly O'Hair <Kelly.Ohair@...>: >>>>>>> >>>>>>> I saw the webrev for a while, and now I can't :^(, but I saw >>>>>>> enough... >>>>>>> >>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>> >>>>>>>>>> 2009/10/7 Andrew John Hughes <gnu_andrew@...>: >>>>>>> >>>>>>> ...[snip]... >>>>>>>>>> >>>>>>>>>> I found a number of issues with the current version: >>>>>>>>>> >>>>>>>>>> * The drop zips are expected to be in a share/jdk7-drops >>>>>>>>>> subdirectory >>>>>>>>>> of the devtools directory. This doesn't really work outside Sun's >>>>>>>>>> internal setup. I've added support for ALT_DROP_DIR which can be >>>>>>>>>> used >>>>>>>>>> to specify an exact path to the zips. If this is not set, the old >>>>>>>>>> devtools behaviour is used. >>>>>>> >>>>>>> I'm concerned about the name dropdir (your master copy location) vs. >>>>>>> drop.dir >>>>>>> (destination for the exploded contents) in the property names. Seems >>>>>>> confusing. >>>>>>> I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR >>>>>>> and >>>>>>> drop.bundle.dir? >>>>>>> >>>>>> >>>>>> Yes, I noticed drop.dir after posting the webrev and agree it's >>>>>> confusing. Would just making them ALT_DROPS_DIR and drops.dir not be >>>>>> sufficient? drop.bundle seems a little verbose and both mean the same >>>>>> thing to me at least. >>>>> >>>>> I'm ok with ALT_DROPS_DIR and drops.dir. >>>>> >>>>>> >>>>>>>>>> * The zips are being downloaded and extracted in the source >>>>>>>>>> directory, >>>>>>>>>> which could be read only. I've changed this so they are written >>>>>>>>>> to >>>>>>>>>> the build directory like everything else. >>>>>>> >>>>>>> It turns out that we need this drop.dir to be in the source area if >>>>>>> we want the openjdk source zip bundles, created by RE, to include >>>>>>> the drop sources. These source bundles are created by bundling up >>>>>>> everything in the forest, prior to building, so the drop.dir needs >>>>>>> to be in the forest somehow. Otherwise, the bundling logic has to >>>>>>> merge two separate source trees, or different roots. >>>>>>> I was given a requirement that the openjdk source bundles include >>>>>>> these >>>>>>> drop sources, easiest answer was drop.dir in the repo. >>>>>>> Not an unsurmountable problem, I avoided the more complicated path. >>>>>>> >>>>>>> I know that becomes an issue if the repository or source is in a >>>>>>> read-only area, but that's not the only situation in the openjdk I >>>>>>> suspect. >>>>>>> I assumed someone building from a read-only area could set >>>>>>> drop.dir to some other location. >>>>>>> >>>>>> >>>>>> Would it not make more sense for RE to set the drop.dir property into >>>>>> the source directory, given it's that build that's abnormal (needing >>>>>> to distribute a post build tree in effect)? >>>>> >>>>> I will look into that. You have convinced me. ;^) >>>>> >>>>>> >>>>>>> Not sure what to say. >>>>>>> >>>>>>> How important is it for the community that the openjdk source bundles >>>>>>> include these drop sources? e.g. ones at >>>>>>> http://download.java.net/openjdk/jdk7/ >>>>>>> If they are not included, when the openjdk source bundles are built, >>>>>>> they will need to download the jaxp and jaxws drop bundles at build >>>>>>> time. >>>>>>> >>>>>> >>>>>> I obviously can't speak for everyone, but for IcedTea7 we don't even >>>>>> use the download bundles any more. We grab from the IcedTea forest >>>>>> instead, which allows patches which didn't make a bxx release to be >>>>>> applied there once and used in releases. We did this for the security >>>>>> fixes with Milestone 4/1.11. >>>>>> >>>>>> I've already added downloading of the jaxp, jaxws and jaf bundles to >>>>>> the IcedTea build; it's this process that resulted in this webrev. >>>>>> This has two advantages; we check all the zips/tarballs at the same >>>>>> point in the build (the JAXP and JAXWS builds are then pointed at the >>>>>> directory IcedTea uses for them) and we check the MD5 sums of the >>>>>> downloads or pre-existing zips. I don't know if the latter could be >>>>>> incorporated into the OpenJDK build somehow. At present, there's no >>>>>> guarantee that these zips are valid. >>>>>> >>>>>> The rules look like this: >>>>>> >>>>>> stamps/download-jaxp-drop.stamp: >>>>>> mkdir -p drops >>>>>> if USE_ALT_JAXP_DROP_ZIP >>>>>> ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) >>>>>> endif >>>>>> if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ >>>>>> | $(MD5SUM) --check ; \ >>>>>> then \ >>>>>> if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ >>>>>> then \ >>>>>> mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ >>>>>> fi ; \ >>>>>> $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O >>>>>> drops/$(JAXP_DROP_ZIP); \ >>>>>> fi ; >>>>>> mkdir -p stamps >>>>>> touch stamps/download-jaxp-drop.stamp >>>>>> >>>>>> ALT_JAXP_DROP_ZIP gets set if the user specifies >>>>>> --with-jaxp-drop-zip=<path> to configure. WGET and MD5SUM are the >>>>>> respective binaries as located by configure and DROP_URL is the >>>>>> kenai.com URL as in the jaxws.properties and jaxp.properties files: >>>>>> >>>>>> DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download >>>>>> JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip >>>>>> JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 >>>>>> JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip >>>>>> JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 >>>>>> JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip >>>>>> JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d >>>>> >>>>> Ah... so my checksum logic in the ant script will serve as a >>>>> double check. >>>>> >>>>> Unless you are changing the bundles and rebundling them... >>>>> nobody does that, ... do they??? >>>>> Ah, if they do, they would need to change the property value >>>>> holding the checksum. >>>>> >>>>> -kto >>>>> >>>>>> >>>>>>> -kto >>>>>>> >>>>>>>>>> The webrev for these changes is here: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>>>>>>>> >>>>>>>>>> I've committed this to IcedTea already. Does this look ok for >>>>>>>>>> build >>>>>>>>>> also? >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> Kelly, >>>> >>>> Does all this mean we can somewhat simplify the list of forests on >>>> hg.o.j.n, by removing jdk7/{corba,jaxp,jaxws} and the corresponding -gate >>>> forests? >>>> >>>> -- Jon >>> >>> No. Not yet. In theory, what little logic is left in jaxp and jaxws >>> (corba has not changed), could be folded up into the top repo >>> or the jdk repo, and you could empty out jaxp and jaxws repos >>> entirely. But I had no plans to do so. >>> >>> What this does is leave a small set of ant scripts and a >>> Makefile over it, in these repos. The build logic is about all >>> that is there, and it will get the jaxp or jaxws source bundle drops, >>> and build them. This change will delete the original sources from >>> the repo, to guarantee they are no longer used. >>> The detailed management of those sources is completely under >>> the control of the jaxp and jaxws teams/projects. >>> >>> The selection of which drop bundles the jdk7 project uses is defined in >>> the jaxp/jaxp.properties and jaxws/jaxws.properties files. >>> >>> -kto >> >> Kelly, >> >> I was not referring to the jaxp/jaxws/corba repositories in each forest. >> It seemed like we had (mostly unused) forests for integrating >> jaxp,jaxws,corba stuff. Specifically: >> >> >> *jdk7/jaxp* <http://hg.openjdk.java.net/jdk7/jaxp/> jaxp >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp/archive/tip.tar.bz2> >> *jdk7/jaxp-gate* <http://hg.openjdk.java.net/jdk7/jaxp-gate/> jaxp >> (gate) build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/archive/tip.tar.bz2> >> *jdk7/jaxp-gate/corba* <http://hg.openjdk.java.net/jdk7/jaxp-gate/corba/> >> jaxp (gate) build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/corba/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/corba/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/corba/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/corba/archive/tip.tar.bz2> >> *jdk7/jaxp-gate/hotspot* >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/hotspot/> jaxp (gate) >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/hotspot/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/hotspot/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/hotspot/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/hotspot/archive/tip.tar.bz2> >> *jdk7/jaxp-gate/jaxp* <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxp/> >> jaxp (gate) build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxp/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxp/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxp/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxp/archive/tip.tar.bz2> >> *jdk7/jaxp-gate/jaxws* <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxws/> >> jaxp (gate) build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxws/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxws/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxws/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jaxws/archive/tip.tar.bz2> >> *jdk7/jaxp-gate/jdk* <http://hg.openjdk.java.net/jdk7/jaxp-gate/jdk/> jaxp >> (gate) build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jdk/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jdk/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jdk/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/jdk/archive/tip.tar.bz2> >> *jdk7/jaxp-gate/langtools* >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/langtools/> jaxp (gate) >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/langtools/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/langtools/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/langtools/archive/tip.tar.gz> | >> bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp-gate/langtools/archive/tip.tar.bz2> >> *jdk7/jaxp/corba* <http://hg.openjdk.java.net/jdk7/jaxp/corba/> >> jaxp build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp/corba/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp/corba/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp/corba/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp/corba/archive/tip.tar.bz2> >> *jdk7/jaxp/hotspot* <http://hg.openjdk.java.net/jdk7/jaxp/hotspot/> jaxp >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp/hotspot/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp/hotspot/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp/hotspot/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp/hotspot/archive/tip.tar.bz2> >> *jdk7/jaxp/jaxp* <http://hg.openjdk.java.net/jdk7/jaxp/jaxp/> jaxp >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp/jaxp/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp/jaxp/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp/jaxp/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp/jaxp/archive/tip.tar.bz2> >> *jdk7/jaxp/jaxws* <http://hg.openjdk.java.net/jdk7/jaxp/jaxws/> >> jaxp build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp/jaxws/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp/jaxws/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp/jaxws/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp/jaxws/archive/tip.tar.bz2> >> *jdk7/jaxp/jdk* <http://hg.openjdk.java.net/jdk7/jaxp/jdk/> jaxp >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp/jdk/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp/jdk/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp/jdk/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp/jdk/archive/tip.tar.bz2> >> *jdk7/jaxp/langtools* <http://hg.openjdk.java.net/jdk7/jaxp/langtools/> >> jaxp build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxp/langtools/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxp/langtools/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxp/langtools/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxp/langtools/archive/tip.tar.bz2> >> *jdk7/jaxws* <http://hg.openjdk.java.net/jdk7/jaxws/> jaxws >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws/archive/tip.tar.bz2> >> *jdk7/jaxws-gate* <http://hg.openjdk.java.net/jdk7/jaxws-gate/> >> jaxws (gate) build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/archive/tip.tar.bz2> >> *jdk7/jaxws-gate/corba* >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/corba/> jaxws (gate) >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/corba/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/corba/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/corba/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/corba/archive/tip.tar.bz2> >> *jdk7/jaxws-gate/hotspot* >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/hotspot/> jaxws (gate) >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/hotspot/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/hotspot/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/hotspot/archive/tip.tar.gz> | >> bz2 <http://hg.openjdk.java.net/jdk7/jaxws-gate/hotspot/archive/tip.tar.bz2> >> *jdk7/jaxws-gate/jaxp* <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxp/> >> jaxws (gate) build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxp/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxp/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxp/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxp/archive/tip.tar.bz2> >> *jdk7/jaxws-gate/jaxws* >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxws/> jaxws (gate) >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxws/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxws/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxws/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jaxws/archive/tip.tar.bz2> >> *jdk7/jaxws-gate/jdk* <http://hg.openjdk.java.net/jdk7/jaxws-gate/jdk/> >> jaxws (gate) build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jdk/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jdk/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jdk/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/jdk/archive/tip.tar.bz2> >> *jdk7/jaxws-gate/langtools* >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/langtools/> jaxws (gate) >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/langtools/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/langtools/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/langtools/archive/tip.tar.gz> | >> bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws-gate/langtools/archive/tip.tar.bz2> >> *jdk7/jaxws/corba* <http://hg.openjdk.java.net/jdk7/jaxws/corba/> jaxws >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws/corba/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws/corba/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws/corba/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws/corba/archive/tip.tar.bz2> >> *jdk7/jaxws/hotspot* <http://hg.openjdk.java.net/jdk7/jaxws/hotspot/> >> jaxws build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws/hotspot/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws/hotspot/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws/hotspot/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws/hotspot/archive/tip.tar.bz2> >> *jdk7/jaxws/jaxp* <http://hg.openjdk.java.net/jdk7/jaxws/jaxp/> >> jaxws build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws/jaxp/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws/jaxp/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws/jaxp/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws/jaxp/archive/tip.tar.bz2> >> *jdk7/jaxws/jaxws* <http://hg.openjdk.java.net/jdk7/jaxws/jaxws/> jaxws >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws/jaxws/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws/jaxws/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws/jaxws/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws/jaxws/archive/tip.tar.bz2> >> *jdk7/jaxws/jdk* <http://hg.openjdk.java.net/jdk7/jaxws/jdk/> jaxws >> build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws/jdk/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws/jdk/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws/jdk/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws/jdk/archive/tip.tar.bz2> >> *jdk7/jaxws/langtools* <http://hg.openjdk.java.net/jdk7/jaxws/langtools/> >> jaxws build-dev@... 20 months ago RSS >> <http://hg.openjdk.java.net/jdk7/jaxws/langtools/rss-log> | zip >> <http://hg.openjdk.java.net/jdk7/jaxws/langtools/archive/tip.zip> | gz >> <http://hg.openjdk.java.net/jdk7/jaxws/langtools/archive/tip.tar.gz> | bz2 >> <http://hg.openjdk.java.net/jdk7/jaxws/langtools/archive/tip.tar.bz2> >> >> >> > > DOH! Sorry... > > Yes, these jaxp and jaxws forests can probably go away, we won't > be using them. > > The current plan is that jaxp/jaxws changes (new bundles) will go > through the TL forest. > > > -kto > I'm guilty of also thinking that Jonathan was referring to the jaxws and jaxp repositories per forest, rather than the specific forests. On that note, i18n could probably die too because apparently that team always use the swing forest for commits. It would be nice to one day get rid of the jaxp and jaxws trees too. I don't actually see why they were created as trees to begin with, given they've always been upstream and not a source of many commits. The one to actual split up would be jdk, as I can feel Mercurial struggling with it a bit already on jdk7. But I don't know how feasible that is, if at all. Maybe Jigsaw will help there. One thing that does worry me -- what happens when the jaxws or jaxp code needs security updates? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by joe.darcy
::
Rate this Message:
Andrew John Hughes wrote:
> 2009/10/23 Kelly O'Hair <Kelly.Ohair@...>: > >> Jonathan Gibbons wrote: >> >>> Kelly O'Hair wrote: >>> >>>> Jonathan Gibbons wrote: >>>> >>>>> Kelly O'Hair wrote: >>>>> [big snip] >> DOH! Sorry... >> >> Yes, these jaxp and jaxws forests can probably go away, we won't >> be using them. >> >> The current plan is that jaxp/jaxws changes (new bundles) will go >> through the TL forest. >> >> >> -kto >> >> > > I'm guilty of also thinking that Jonathan was referring to the jaxws > and jaxp repositories per forest, rather than the specific forests. > On that note, i18n could probably die too because apparently that team > always use the swing forest for commits. > > It would be nice to one day get rid of the jaxp and jaxws trees too. > I don't actually see why they were created as trees to begin with, > given they've always been upstream and not a source of many commits. > The one to actual split up would be jdk, as I can feel Mercurial > struggling with it a bit already on jdk7. But I don't know how > feasible that is, if at all. Maybe Jigsaw will help there. > > One thing that does worry me -- what happens when the jaxws or jaxp > code needs security updates? > Yes, the need to support security fixes was considered as part of this new delivery model. Ultimately a revised source bundle with the security fixes will need to be produced. Until then, the fixes can be represented as patches which are applied to the sources before the build. Kelly can speak to the implementation details of the patch mechanism. -Joe |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by Kelly O'Hair
::
Rate this Message:
Joseph D. Darcy wrote: > Andrew John Hughes wrote: >> 2009/10/23 Kelly O'Hair <Kelly.Ohair@...>: >> >>> Jonathan Gibbons wrote: >>> >>>> Kelly O'Hair wrote: >>>> >>>>> Jonathan Gibbons wrote: >>>>> >>>>>> Kelly O'Hair wrote: >>>>>> > > [big snip] >>> DOH! Sorry... >>> >>> Yes, these jaxp and jaxws forests can probably go away, we won't >>> be using them. >>> >>> The current plan is that jaxp/jaxws changes (new bundles) will go >>> through the TL forest. >>> >>> >>> -kto >>> >>> >> >> I'm guilty of also thinking that Jonathan was referring to the jaxws >> and jaxp repositories per forest, rather than the specific forests. >> On that note, i18n could probably die too because apparently that team >> always use the swing forest for commits. >> >> It would be nice to one day get rid of the jaxp and jaxws trees too. >> I don't actually see why they were created as trees to begin with, >> given they've always been upstream and not a source of many commits. >> The one to actual split up would be jdk, as I can feel Mercurial >> struggling with it a bit already on jdk7. But I don't know how >> feasible that is, if at all. Maybe Jigsaw will help there. >> >> One thing that does worry me -- what happens when the jaxws or jaxp >> code needs security updates? >> > > Yes, the need to support security fixes was considered as part of this > new delivery model. Ultimately a revised source bundle with the > security fixes will need to be produced. Until then, the fixes can be > represented as patches which are applied to the sources before the > build. Kelly can speak to the implementation details of the patch > mechanism. It's crude, but should serve in an emergency. See the patches/README. After a bundle is unzipped, all patches are applied, none right now. I hope that we can always just get updated bundles. Originally, the jaxp and jaxws (and corba) workspaces were created mainly as a place to move files from (trim) the original "j2se" workspace, and we had no idea where we were going with it all, except that we knew these were out of place in the j2se workspace, which became the jdk repository. The jaxp and jaxws repos could just go away someday, but I'll leave that for another day. ;^) Let's just call it evolution. ;^) -kto > > -Joe |
|
|
Re: 6856630: Restructure jaxp/jaxws repository
by jonathan.gibbons
::
Rate this Message:
Kelly O'Hair wrote:
> > > Joseph D. Darcy wrote: >> Andrew John Hughes wrote: >>> 2009/10/23 Kelly O'Hair <Kelly.Ohair@...>: >>> >>>> Jonathan Gibbons wrote: >>>> >>>>> Kelly O'Hair wrote: >>>>> >>>>>> Jonathan Gibbons wrote: >>>>>> >>>>>>> Kelly O'Hair wrote: >>>>>>> >> >> [big snip] >>>> DOH! Sorry... >>>> >>>> Yes, these jaxp and jaxws forests can probably go away, we won't >>>> be using them. >>>> >>>> The current plan is that jaxp/jaxws changes (new bundles) will go >>>> through the TL forest. >>>> >>>> >>>> -kto >>>> >>>> >>> >>> I'm guilty of also thinking that Jonathan was referring to the jaxws >>> and jaxp repositories per forest, rather than the specific forests. >>> On that note, i18n could probably die too because apparently that team >>> always use the swing forest for commits. >>> >>> It would be nice to one day get rid of the jaxp and jaxws trees too. >>> I don't actually see why they were created as trees to begin with, >>> given they've always been upstream and not a source of many commits. >>> The one to actual split up would be jdk, as I can feel Mercurial >>> struggling with it a bit already on jdk7. But I don't know how >>> feasible that is, if at all. Maybe Jigsaw will help there. >>> >>> One thing that does worry me -- what happens when the jaxws or jaxp >>> code needs security updates? >>> >> >> Yes, the need to support security fixes was considered as part of >> this new delivery model. Ultimately a revised source bundle with the >> security fixes will need to be produced. Until then, the fixes can >> be represented as patches which are applied to the sources before the >> build. Kelly can speak to the implementation details of the patch >> mechanism. > > It's crude, but should serve in an emergency. See the patches/README. > After a bundle is unzipped, all patches are applied, none right now. > > I hope that we can always just get updated bundles. > > Originally, the jaxp and jaxws (and corba) workspaces were created > mainly as a place to move files from (trim) the original "j2se" > workspace, > and we had no idea where we were going with it all, except that we > knew these were out of place in the j2se workspace, which became > the jdk repository. > > The jaxp and jaxws repos could just go away someday, but I'll leave > that for another day. ;^) > > Let's just call it evolution. ;^) > > -kto > > >> >> -Joe repositories into the root repository such that the only perceivable difference would be where the hidden .hg files are. In other words, the current jaxp and jaxws repos simply become subdirectories of the root repository, with no other changes to the makefiles being required. -- Jon |
| < Prev | 1 - 2 - 3 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
