Re: [higgins-dev] Two project-related questions

[Michael McIntosh <mikemci@xxxxxxxxxx>]

higgins-dev-bounces@xxxxxxxxxxx wrote on 01/05/2007 09:23:34 PM:

> First the easy one:
> 
> The STS projects maintain a build and build/classes directory.  I 
> find this cumbersome as build output goes in here and then I have to
> do cvsignore on the content (jars, wars, roots of packages).  Is 
> there a reason for having these checked in?  If not, I'd like to 
> remove them from CVS and let the build script create them as needed.

No reason for them to be checked in - they were added automagically when 
the project was added to CVS thru Eclipse.

> Second one has to do with the criteria for deciding when to create a
> project versus adding to an existing one.  For example:  In the IdAS
> project, we've added packages like org.eclipse.higgins.idas. and 
> org.eclipse.higgins.idas.impl, but when we added org.eclipse.
> higgins.idas.context.model* we did it by adding two new projects. 
> There are 6 STS projects.  I think I know why the extensions are 
> their own projects.  Less sure about the bindings. 

So I'll start with the easy ones ;-):

Token Extensions are optional and need to be able to be added to the 
framework after the framework is built. Rather than treating Username and 
SAML as special I wanted to make sure they were treated the same as any 
other Token Extension - so they are each in their own JAR.

Now the harder ones:
I'd wanted to separate the guts of the axis1x binding from the code that 
gets generated when WSDL2Java gets run, to avoid overwriting it when/if I 
rerun WSDL2Java. So the binding guts are in 
org.eclipse.higgins.sts.binding.axis1x.core. The 
org.eclipse.higgins.sts.binding.axis1x.service contains the actual 
WSDL2Java generated servlet skeleton code that gets invoked when requests 
are received. The org.eclipse.higgins.sts.binding.axis1x.service 
invokes/depends on the org.eclipse.higgins.sts.binding.axis1x.core. The 
org.eclipse.higgins.sts.binding.axis1x.core requires access to the 
WSDL2Java generated classes representing request and response values. In 
order to avoid the cyclical dependancy, these classes were moved to 
org.eclipse.higgins.sts.binding.axis1x.types.
It would be possible to merge the axs1x binding files into a single 
package, but that would require special care if an attempt was made to 
regen from new WSDL (or using an updated WSDL2Java).
I suppose I could merge these if someone really wanted that done.

So, for now:
org.eclipse.higgins.sts.core depends on no other org.eclipse.higgins.sts.* 
packages.
org.eclipse.higgins.sts.binding.axis1x.types depends on no other 
org.eclipse.higgins.sts.* packages.
org.eclipse.higgins.sts.extension.samltoken depends on
        org.eclipse.higgins.sts.core.
org.eclipse.higgins.sts.extension.usernametoken depends on
        org.eclipse.higgins.sts.core.
org.eclipse.higgins.sts.extension.usernametoken depends on
        org.eclipse.higgins.sts.core.
org.eclipse.higgins.sts.binding.axis1x.core depends on
        org.eclipse.higgins.sts.binding.axis1x.types, and
        org.eclipse.higgins.sts.core.
org.eclipse.higgins.sts.binding.axis1x.service depends on
        org.eclipse.higgins.sts.binding.axis1x.types, and
        org.eclipse.higgins.sts.binding.axis1x.core.




> 
> Jim_______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev