Re: [wtp-dev] Facet's not asking runtime/server about libraries -intentional or error ?
by Max Rydahl Andersen
> My guess as to the "why" question is that this hasn't been requested by
> anyone before. Right now only jst.java and module facets use the
> classpath provider facility, but the facility was designed so that any
> facet could use it if it makes sense for that facet. I do not know the
> design and implementation details of how JSF and JPA facets manage their
> libraries, but I would suggest opening enhancement requests (one for JSF
> and one for JPA) to continue this conversation and to figure out if this
> change makes sense for these facets.
Will do that - but just wondering what the intended behavior is; I would
expect that facet's should be encouraged to do similar things when it
comes to libraries....and the "Server provides libraries" option for
these two would indicate they at least should let the runtime know about
the changes.
In any case: Is there a way for a runtime to know which facet's are
being added to a project that it is connected to ?
e.g. if I move a project from runtime/server A to runtime/server B the
classpath should be updated - but that does not seem to happen. Should
it not ?
/max
> - Konstantin
>
>
> -----Original Message-----
> From: wtp-dev-bounces(a)eclipse.org [mailto:wtp-dev-bounces@eclipse.org]
> On Behalf Of Rob Stryker
> Sent: Monday, August 06, 2007 2:57 PM
> To: General discussion of project-wide or architectural issues.
> Cc: jbosstools-dev(a)lists.jboss.org
> Subject: Re: [wtp-dev] Facet's not asking runtime/server about libraries
> -intentional or error ?
>
> The type of "alert" not being given by the JSF and JPA facets are
> usually called by a line similar to the one below:
> ClasspathHelper.addClasspathEntries(project, fv));
>
> The line above alerts the runtime of the facet version's new inclusion
> and is borrowed from the WebFacetInstallDelegate.
>
> I echo Max's query. Why don't the other facets such as JSF / JPA do the
> same?
>
>
>
> Max Rydahl Andersen wrote:
>> Hi,
>>
>> I noticed today that when enabling JSF or JPA on projects neither of
>> them consults the server/runtime about which jars that are relevant
>> for it.
>>
>> dynamic web and the java facet does....why not jpa and jsf ?
>>
>> some runtimes could return an optimized set of jars if this were done
>> instead of just returning *everything* ....
>>
>> I'm i missing something obvious ?
>>
>> what about JPA projects that won't be dynamic web apps ?
>>
>> /max
>> _______________________________________________
>> wtp-dev mailing list
>> wtp-dev(a)eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
> _______________________________________________
> wtp-dev mailing list
> wtp-dev(a)eclipse.org
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
> Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
> _______________________________________________
> wtp-dev mailing list
> wtp-dev(a)eclipse.org
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
17 years, 3 months
- 1
- 1
Facet's not asking runtime/server about libraries - intentional or error ?
by Max Rydahl Andersen
Hi,
I noticed today that when enabling JSF or JPA on projects neither of
them consults the server/runtime about which jars that are relevant for it.
dynamic web and the java facet does....why not jpa and jsf ?
some runtimes could return an optimized set of jars if this were done
instead of just returning *everything* ....
I'm i missing something obvious ?
what about JPA projects that won't be dynamic web apps ?
/max
17 years, 3 months
- 2
- 1
Release Process
by Marshall Culpepper
Hey guys..
I wanted to hash out the release process we're going to use for the
upcoming betas and GAs of JBossTools and RHDS.
Below I've listed what I think should be our release process moving
forward. This is heavily based on the process we used for JBossIDE, with
some changes to accomodate our new QA resources.
1) All top level components (i.e. "jsf", "richfaces", "hibernatetools",
"as", etc) are given a tag. In the case of major releases (GAs / major
functionality changes), we branch instead of tag. In the case of a
branch, we use HEAD of that branch as the tag (any changes needing to be
made during the release process will be just committed to HEAD in that
branch rather than re-tagging/re-branching)
2) An integration build is ran on those tags. If there are any errors in
the build, the offending components must fix any code/bugs and re-tag.
3) All component owners do smoke testing of their respective code (this
is just a smoke test to ensure things are working properly).
4) If there are any problems in the smoke testing, the component owner
is responsible for making the change, re-tagging, and we will re-run the
integration build (coming back to step #2)
5) Once we have an integration build that everyone is happy with, we
will run the release build, and pass that on to QA for testing. Any
problems in this process go back to step #2 for fixing/re-tagging
(though at this point we continue with release builds instead of
integration builds)
6) When QA gives the thumbs up we can make the release. The build is
uploaded to our update site, which receives one last smoke test from
each component lead. (Any problems are fixed/re-tagged/re-tested).
7) Finally we upload the release to Sourceforge, our build server, the
public update site, and make the announcement on forums, blogs, the
download pages, etc.
--
Marshall Culpepper
Redhat Dev Studio, JBoss Tools
http://jboss.org/tools
email: marshall(a)jboss.org
skype: marshall.culpepper
17 years, 3 months
- 4
- 11