Is there any way to deprecate a dependency so that projects using this
dependency break teh build?
If project a relies on hibernate 3.0 and the rest of the projects in a
working set have moved up to hibernate 3.1, is there any way to
specify that v3.0 is no longer allowed and therefore cause the
I will post this to the maven ng. However, I think this could be a
Continuum feature since Continuum is ultimately responsible for
halting the build process. How can one project that is independent of
other projects know that the version it is using is disallowed unless
some process above (Continu
Is there any way to deprecate a dependency so that projects using this
dependency break the build?
If project a relies on hibernate 3.0 and the rest of the projects in a
working set have moved up to hibernate 3.1, is there any way to
specify that v3.0 is no longer allowed and therefore cause the
Sorry for the simple questions, the docs are still a little light.
Can continuum run integration on various branches, automatically, for
a given project in cvs? My hope is the following:
given a project A, you have the head and a 1.1 branch. Can Continuum
detect that there are multiple branches
I understood that ejb3 functionality will not be built into the
ejb-plugin until the spec is final. It looks like it's all set
(http://www.theserverside.com/news/thread.tss?thread_id=40199). When
can we expect the ejb3 integration in the plugin?
---
etime soon...
On 5/5/06, Tim Kettler <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> what EJB3 specific functionality are you talking about?
>
> -Tim
>
> Todd Orr schrieb:
> > I understood that ejb3 functionality will not be built into the
> > ejb-plugi
Is there some conspiracy to keep this down? It's Jira item is still
marked as trivial. The patch has been up for months. Seriously, far
more "trivial" plugin updates have been released lately. This seems
like such a simple update since the work is already done.
---
This is not so unusual. Consider that I have a similar issue. I have spring
configs that are only used for integration testing. These reside in
src/test/resource. When firing up jetty:run it cannot read those resources
as defined in my web.xml via classpath:resource. Furthermore, the jetty
plugin c
I'm also interested in this project.
On 3/11/06, Marco Mistroni <[EMAIL PROTECTED]> wrote:
> Hello all,
> i have done a J2EE project which includes some EJB3, using Maven2.
> as of now, main limitation (due to its simplicity) is that i am NOT using
> maven-ejb-plugin since i am letting jboss figu
sses-related package, I haven't used the maven-par/ejb3-plugins
> (that's cause there's no more ejb-jar.xml file)
>
> This does not mean they're obsolete - if you have a big, complex ejb3
> project you might still need to create an ejb-jar.xml file, in which case
&g
> > > server-module (contains implementations of SLSBs,depends on
> > > common-module)
> > > pom.xml (JAR packaging)
> > > client-module (swing ui, depends on common-module)
> > > pom.xml
> > >
> > >
> > >
11 matches
Mail list logo