RE: [higgins-dev] build input directories

[Michael McIntosh <mikemci@xxxxxxxxxx>]

Yes Paul is right - and so is Jim. I've implemented the ./lib solution for 
now. I am looking to encourage discussion of whether there is a better 
long term solution.

higgins-dev-bounces@xxxxxxxxxxx wrote on 02/06/2007 12:47:29 AM:

> Sorry. I wasn?t clear. I figured that Mike?s proposal was something 
> that we could and perhaps should do in the short term. I was 
> addressing the long term/best practice, but I wasn?t trying to 
> affect in the short term decisions.
> 
> 
> From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
> Sent: Monday, February 05, 2007 11:15 PM
> To: 'Higgins (Trust Framework) Project developer discussions'
> Subject: RE: [higgins-dev] build input directories
> 
> I think this is a little different from what Mike is proposing. 
> 
> Mike was proposing to add a ./lib directory to each of our higgins 
> eclipse projects and that ./lib directory would (eventually) contain
> *all* the dependency jars for that project.
> 
> You are proposing that each dependency jar would be placed in its 
> own eclipse project and then our higgins eclipse projects would 
> reference these other projects as dependencies (the same way the sts
> axis service project references the sts core project).
> 
> In this way, there is no duplication of jar files, and there's no 
> grouping of them in a single directory either.
> 
> I think this would work fine for the eclipse projects.  And since 
> the generated builds will populate build.xml with *.location 
> properties for all dependency projects, we should be able to build 
> jars and wars in our hand-tooled build scripts as well (it'll just 
> take a bit more doing in terms of war building, as each one will 
> have to be specifically called out rather than pulling *.jar from 
> some directory).
> 
> However, I'm not sure if putting a dependency from projectA to 
> projectB will auto pull in the dependencies that projectB might have.
> 
> Jim
> 
> >>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 2/5/07 7:16 PM >>>
> 
> Mike wrote
> > 
> > Looking for comments.
> > 
> <snip>
> 
> > As was discussed in the F2F, this will eventually result in each 
project
> > potentially duplicating jars that other projects also use.
> > The alternative discussed during the F2F was to create separate 
projects
> > in CVS for each dependent jar.
> > Using a large PSF file we could ensure that each project downloaded 
what
> > they needed and each jar would only be checked in once.
> 
> Yes. Eclipse best practice is (I believe) to create a separate eclipse
> plug-in project for each third party library. This basically means 
creating
> a new plugin project, adding the jar and creating a MANFEST.MF file. 
Then
> eclipse projects can then declare themselves to be dependent on these 
OTHER
> eclipse projects. 
> 
> > Additionally, the Eclipse Orbit project could hold these dependent jar
> > projects for us.
> 
> Yes. And to add these "plugin-wrapped" third party jars to Orbit is 
easy.
> > 
> > Thanks,
> > Mike
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev