You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Colin Sampaleanu <co...@exis.com> on 2003/02/03 18:15:58 UTC
Should project's run via reactor really pollute the main maven jelly
context?
In the process of trying to create some tags to handle attaining goals
while using the parent (maven) goal session, I figured out that running
goals from subprojects via the reactor pollutes the one and only main
maven jelly context.
I question whether having one main jelly context that is always used is
the best way to handle things, and is really adequate? If I build
projects a,b,c via the reactor, and they write a bunch of vars in the
jelly context, and let's say even create customs tags, which also go
into the context, and then in the same maven session build via the
reactor, projects d,e,f, it does not seem correct that any artifacts
created by the first set of projects can pollute the context for the
build of the second set of projects. While I know there is a need for
artifacts create in a subproject to be later used, there is no mechanism
to throw them away. I am thinking in terms of the need to have a global
context vs a local context. Right now maven has only the idea of global
context.
Re: Should project's run via reactor really pollute the main maven
jelly context?
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2003-02-03 at 12:15, Colin Sampaleanu wrote:
> In the process of trying to create some tags to handle attaining goals
> while using the parent (maven) goal session, I figured out that running
> goals from subprojects via the reactor pollutes the one and only main
> maven jelly context.
>
> I question whether having one main jelly context that is always used is
> the best way to handle things, and is really adequate? If I build
> projects a,b,c via the reactor, and they write a bunch of vars in the
> jelly context, and let's say even create customs tags, which also go
> into the context, and then in the same maven session build via the
> reactor, projects d,e,f, it does not seem correct that any artifacts
> created by the first set of projects can pollute the context for the
> build of the second set of projects. While I know there is a need for
> artifacts create in a subproject to be later used, there is no mechanism
> to throw them away. I am thinking in terms of the need to have a global
> context vs a local context. Right now maven has only the idea of global
> context.
No it does not. For each project there is a context, if in the reactor
the contexts are getting mixed up it's an error on my part. Each project
should be completely self-contained including the context used. The
reactor is still a bit wonky but I have been moving to align the actions
of a project with the context for the project. Where this is not working
is oversight no my part.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: Should project's run via reactor really pollute the main maven
jelly context?
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2003-02-03 at 16:01, Colin Sampaleanu wrote:
> Jason van Zyl wrote:
> >
> This is in as
> http://jira.werken.com/secure/ManageAttachments.jspa?id=10426
> I will admit I am somewhat confused though. My initial test this morning
> showed tags defined in a subproject built via the reactor sticking
> around. Then I looked at the code, and it seemed to me you were
> intentionally sharing one global context, which prompted the emails.
> Before uploading the test, for good measure I added a test to see if
> variable defined in the subproject also stick around. These do not. My
> understanding is that both custom tags and variable go in the same
> context, so I do not really understand what is going on; I would have
> expects vars to also show the same problem.
>
> Also, a reminder that you or somebody else with commit access should
> check in the patch for JellyContext vs MavenJellyContext submitted by
> Matthew McGowan.
> http://jira.werken.com/secure/ViewIssue.jspa?key=MAVEN-245
>
Awesome, thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: Should project's run via reactor really pollute the main maven
jelly context?
Posted by Colin Sampaleanu <co...@exis.com>.
Jason van Zyl wrote:
>On Mon, 2003-02-03 at 13:20, Colin Sampaleanu wrote:
>
>
>>Jason van Zyl wrote:
>>
>>>On Mon, 2003-02-03 at 12:15, Colin Sampaleanu wrote:
>>>
>>>>In the process of trying to create some tags to handle attaining goals
>>>>while using the parent (maven) goal session, I figured out that running
>>>>goals from subprojects via the reactor pollutes the one and only main
>>>>maven jelly context.
>>>>
>>>This is a general problem and it looks like something I overlooked in a
>>>single place when the goals for a project are attained.
>>>
>>>Again, the best way to demonstrate what you feel to be a problem is a
>>>touchstone test.
>>>
>>No problem. I actually did do a touchstone test to demonstrate the
>>issue, then I looked at the code in Maven, and figured that you did
>>things this way intentionally, so wrote the email before submitting it
>>as a bug. So I'll enter an issue in Jira with the code...
>>
>>
>Nope, as with everything in Maven the project is the unit of work and
>that's where everything should, and eventually will be localized.
>
>>This is good, because I think the context (or really a Maven version of
>>it), if it doesn't get polluted by reactor builds, is also the place to
>>store the werkz goal session for access by another variant of the
>>attainGoal tag which inherits the session.
>>
>>
>Once the context is used correctly this will happen automatically. If a
>werkz project isn't present then werkz will create one in the context.
>Actually looking at things now I see the one place that would probably
>fix what you see and all the quirks Alexei has noticed. Good eye.
>
>
This is in as
http://jira.werken.com/secure/ManageAttachments.jspa?id=10426
I will admit I am somewhat confused though. My initial test this morning
showed tags defined in a subproject built via the reactor sticking
around. Then I looked at the code, and it seemed to me you were
intentionally sharing one global context, which prompted the emails.
Before uploading the test, for good measure I added a test to see if
variable defined in the subproject also stick around. These do not. My
understanding is that both custom tags and variable go in the same
context, so I do not really understand what is going on; I would have
expects vars to also show the same problem.
Also, a reminder that you or somebody else with commit access should
check in the patch for JellyContext vs MavenJellyContext submitted by
Matthew McGowan.
http://jira.werken.com/secure/ViewIssue.jspa?key=MAVEN-245
Re: Should project's run via reactor really pollute the main maven
jelly context?
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2003-02-03 at 13:20, Colin Sampaleanu wrote:
> Jason van Zyl wrote:
>
> >On Mon, 2003-02-03 at 12:15, Colin Sampaleanu wrote:
> >
> >
> >>In the process of trying to create some tags to handle attaining goals
> >>while using the parent (maven) goal session, I figured out that running
> >>goals from subprojects via the reactor pollutes the one and only main
> >>maven jelly context.
> >>
> >>
> >>
> >
> >This is a general problem and it looks like something I overlooked in a
> >single place when the goals for a project are attained.
> >
> >Again, the best way to demonstrate what you feel to be a problem is a
> >touchstone test.
> >
> >
> >
> No problem. I actually did do a touchstone test to demonstrate the
> issue, then I looked at the code in Maven, and figured that you did
> things this way intentionally, so wrote the email before submitting it
> as a bug. So I'll enter an issue in Jira with the code...
Nope, as with everything in Maven the project is the unit of work and
that's where everything should, and eventually will be localized.
> This is good, because I think the context (or really a Maven version of
> it), if it doesn't get polluted by reactor builds, is also the place to
> store the werkz goal session for access by another variant of the
> attainGoal tag which inherits the session.
Once the context is used correctly this will happen automatically. If a
werkz project isn't present then werkz will create one in the context.
Actually looking at things now I see the one place that would probably
fix what you see and all the quirks Alexei has noticed. Good eye.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: Should project's run via reactor really pollute the main maven
jelly context?
Posted by Colin Sampaleanu <co...@exis.com>.
Jason van Zyl wrote:
>On Mon, 2003-02-03 at 12:15, Colin Sampaleanu wrote:
>
>
>>In the process of trying to create some tags to handle attaining goals
>>while using the parent (maven) goal session, I figured out that running
>>goals from subprojects via the reactor pollutes the one and only main
>>maven jelly context.
>>
>>
>>
>
>This is a general problem and it looks like something I overlooked in a
>single place when the goals for a project are attained.
>
>Again, the best way to demonstrate what you feel to be a problem is a
>touchstone test.
>
>
>
No problem. I actually did do a touchstone test to demonstrate the
issue, then I looked at the code in Maven, and figured that you did
things this way intentionally, so wrote the email before submitting it
as a bug. So I'll enter an issue in Jira with the code...
This is good, because I think the context (or really a Maven version of
it), if it doesn't get polluted by reactor builds, is also the place to
store the werkz goal session for access by another variant of the
attainGoal tag which inherits the session.
Re: Should project's run via reactor really pollute the main maven
jelly context?
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2003-02-03 at 12:15, Colin Sampaleanu wrote:
> In the process of trying to create some tags to handle attaining goals
> while using the parent (maven) goal session, I figured out that running
> goals from subprojects via the reactor pollutes the one and only main
> maven jelly context.
>
This is a general problem and it looks like something I overlooked in a
single place when the goals for a project are attained.
Again, the best way to demonstrate what you feel to be a problem is a
touchstone test.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society