I agree more details/design is needed for the "web" source folders... The output directory could be optional or better yet, the server could determine if any additional assembly is required.
I don't think the output location would change depending on server location because it is intended to specify spec level requirment, not server specific metatdata locations.
We need to support the Tomcat case where a single output location can be assembled, and this content would either be "built" at development time, or assembled at publish time.
What are your thoughts?
This proposal would come from WTP initially, as it is really solving a domain specific problem.
Thanks - Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email: [EMAIL PROTECTED]
Phone: 919-254-1848 (T/L: 444)
| "Konstantin Komissarchik"
<[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 09/08/2005 01:49 PM
|
|
We definitely like the direction that this is heading in. :)
The combination of 2 and 4 should give a tremendous amount of flexibility to the users. I am a bit confused by 3 (“web” source folders). What would the platform provide to support this? Associating an output directory with these source folders seems a bit questionable too. Isn’t the output location going to change for web folders depending for which server the project is being assembled?
- Konstantin
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chuck Bridgham
Sent: Wednesday, September 07, 2005 12:04 PM
To: General discussion of project-wide or architectural issues.
Subject: [wtp-dev] For review: Alternate flexible workspace proposals
Hi everyone,
Please review the document posted below, here is the first section:
Recently we have had two very productive meetings with the eclipse platform team, in understanding some of
the proposals for V3.2 that give WTP more options in regards to flexible workspaces/projects. During these
meetings 4 proposals were discussed that tackle different aspects of "flexible workspaces" Much of the existing
flexible project internal api is an implementation that satisfies many of the requirements declared last year.
Many of these scenarios should be solved at the platform level, and our current WTP api has a few serious
restrictions that forces us to re-evaluate our direction.
http://www.eclipse.org/webtools/jst/components/j2ee/proposals/WTPFlexibleProjectProposals.html
Please respond with your feedback soon.
Thanks - Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email: [EMAIL PROTECTED]
Phone: 919-254-1848 (T/L: 444)_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
