geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: 1.1.1 Status - XSD and DTD issues
Date Fri, 18 Aug 2006 19:52:37 GMT
I've uploaded a preliminary version of the proposed schema jar at

We should be able to remove all the schemas and xmlbeans stuff from  
j2ee-schema module and instead have a geronimo-dependency.xml element  
to pull in the above jar.

In m1 these geronimo-dependency.xml files are generated by our  
dependency plugin, but for m2 you have to write it yourself and put  
it in src/resources2/META-INF/geronimo-dependency.xml

I have some more work to do on the proposed new module to put the  
xmlbeans stuff in a separate profile so the source is not generated  
each time it's run.  I'll open a jira with the new module when I get  
it working better.  I assume this has to go through RTC.... maybe it  
can be kind of quick since we are basically just changing where we  
build and compile the exact same classes as before.

david jencks

On Aug 18, 2006, at 10:46 AM, David Jencks wrote:

> On Aug 18, 2006, at 10:36 AM, David Blevins wrote:
>> I personally don't know why we bother to regenerate that tree on  
>> every build as those schemas are not going to change.  Let's just  
>> build them once, publish the jars, delete the schemas and be done  
>> with it.
> I think this will minimize our legal exposure.  I'll work on a  
> specs module for this.  I might need some m2 help, my plan is to  
> use a profile so that  using the profile we compile the schemas  
> using xmlbeans, letting xmlbeans download the schemas direct from  
> sun, and having xmlbeans put the results in appropriate places in  
> src.  We can then check the results in by hand.  The normal build  
> can simply compile these generated sources.
> We may need another step to put apache headers on the generated  
> code.  Some of the generated stuff is binary files, which AFAIK  
> cannot be modified to include a header.  I'll probably need help  
> with this part.
> Is everyone OK with putting this into specs?  Any ideas for a  
> better place?
> thanks
> david jencks
>> -David
>> On Aug 18, 2006, at 9:45 AM, David Jencks wrote:
>>> On Aug 18, 2006, at 9:22 AM, Geir Magnusson Jr wrote:
>>>> If they are only used during the build process, then don't re- 
>>>> distribute
>>>> and therefore this issue then seems out of the critical path for  
>>>> 1.1.1
>>>> and can be solved for
>>> They are not needed at runtime, but xmlbeans packs the source  
>>> schemas into the jar with its other binary artifacts.  We might  
>>> be able to prevent their inclusion into our jars, but I don't see  
>>> how having them in svn is not redistribution, so I think we need  
>>> allowable copies of the j2ee 1.4 schemas in our svn.
>>> thanks
>>> david jencks
>>>> gier
>>>> Matt Hogstrom wrote:
>>>>> They are used by XMLBeans during the build process.  I guess we  
>>>>> could do
>>>>> a one-time generation of the XMLBeans classes but I'd be more
>>>>> comfortable with Jencks' input.  If you don't have the schemas  
>>>>> you'd
>>>>> have to have network connectivity to build I suspect.
>>>>> Aaron Mulder wrote:
>>>>>> Can't we just ship without those?  We have pointers to them on  
>>>>>> our web
>>>>>> site at -- is there any
>>>>>> additional reason we need them at runtime (e.g. does XMLBeans  
>>>>>> use the
>>>>>> actual schema to validate at runtime)?
>>>>>> Thanks,
>>>>>>     Aaron
>>>>>> On 8/18/06, Matt Hogstrom <> wrote:
>>>>>>> All,
>>>>>>> For those wondering where the Geronimo 1.1.1 release is at  
>>>>>>> here is a
>>>>>>> quick summary and battle plan.
>>>>>>> John Sisson discovered that we have several DTD and XSDs  
>>>>>>> included in
>>>>>>> our build that are copies of
>>>>>>> Sun's original material.  The copyright in the material seems
>>>>>>> indicate that we cannot
>>>>>>> redistribute the content.  Unfortunately, as Geir has pointed
>>>>>>> out,
>>>>>>> that there is no clear way to
>>>>>>> interpret the license and we should manually generate these 

>>>>>>> to stay
>>>>>>> legal and avoid any appearance
>>>>>>> of impropriety.
>>>>>>> The documents in question reside in both the distribution of
>>>>>>> source as well as the server
>>>>>>> itself.  It appears that other open source and commercial  
>>>>>>> vendors do
>>>>>>> distribute these documents in
>>>>>>> their original form but the ASF does not have a clear  
>>>>>>> indication that
>>>>>>> we can follow this same
>>>>>>> practice.  You can find the documents in
>>>>>>> $G_BUILD_TREE/modules/j2ee-schema/src/* as well as the
>>>>>>> distributions in $G_DIST/schema/* directories.
>>>>>>> The documents are identified in JIRA
>>>>>>> I'd like to ask anyone that has some spare moments to help  
>>>>>>> out with
>>>>>>> putting these together.
>>>>>>> Basically, you need to refer to the appropriate specification
>>>>>>> and
>>>>>>> type in the XML exactly like it is
>>>>>>> represented for actual elements and either omit or paraphrase
>>>>>>> the
>>>>>>> information embedded in comments
>>>>>>> so we do not violate Sun's copyright.
>>>>>>> I know this is frustrating but for their own reasons Sun has
>>>>>>> imposed
>>>>>>> this unfriendly copyright and
>>>>>>> we need to abide by it.  We are protecting The ASF, Geronimo
>>>>>>> and our
>>>>>>> users.
>>>>>>> If you are working on a document please update the above JIRA
>>>>>>> indicate it is partial so others
>>>>>>> can see what remains.  Please check the new schemas into their
>>>>>>> respective replacements.  When the
>>>>>>> replacements are complete we'll build a new distribution and
>>>>>>> run it
>>>>>>> through a full CTS test to
>>>>>>> validate our work.
>>>>>>> Please also consider working with a partner so you can cross
>>>>>>> check
>>>>>>> each other's work.
>>>>>>> Thanks in advance for your patience and help with this  
>>>>>>> important issue.
>>>>>>> Also, if others have input into the process that I have  
>>>>>>> missed please
>>>>>>> provide it as well.
>>>>>>> Thanks to John and Geir for discovering and mediating on this
>>>>>>> issue.

View raw message