Re: [tools] tools launching and javac

[Mark Hindess <ma...@googlemail.com>]

On 25 May 2006 at 7:46, Geir Magnusson Jr <ge...@pobox.com> wrote:
> 
> Tim Ellison wrote:
> > Geir Magnusson Jr wrote:
> >> Tim Ellison wrote:
> >>> This is still work in progress, but thought it would be good to give a
> >>> quick update on where I am at the moment:
> > <snip>
> >>> Now you can run javac.
> >> Very cute!  Do you intend module/tools to remain not part of the build?
> > 
> > It will become part of the build once it is as-good-as done.
> > 
> > I'm trying to do a balancing act between /not/ dumping my junk into SVN
> > as I go along, and developing in the open | collaboratively.
> > Suggestions for re-balancing are more than welcome.
> 
> Only suggestion is to do a branches/tim/stuff1, work in there if you
> want people to comment (with the bonus of having it in SVN in case of
> problem).
>
> It's COW so the space usage won't be that bad, and you can just delete
> when done.

While that's true, I think that development on branches has other costs:

 * merging back into trunk

 * fewer people will pay attention - nothing personal but I might be
   less inclined to scan commits in branches/tim than trunk ;-)

Personally, I think development is moving fast enough that it's not a
problem having it in trunk.  If it hadn't been in trunk, I might have
been less inclined to test it ... and not had the incentive to fix the
bugs (HARMONY-510) on my platform of choice.

Obviously, we should avoid breaking things like this for too long but I
think the occasional breakage is a fair price to pay for not having the
other costs.

Of course, I seem to be the only one who even noticed this problem.

Regards,
 Mark.

> > <snip>
> > 
> >>> - For now, the o.a.h.tools.javac.Main wrapper looks for the compiler in
> >>> a hard-coded JAR filename (ecj_3.2RC5.jar).  Just wondering whether to
> >>> embed that JAR in the tools.jar, or look for the compiler in *.jar, or
> >>> ...?
> >> Can we give it a 'known' pattern like "harmony_javac_ecj_3.2rc5.jar" or
> >> such so we can mechanically find it w/o a long search, yet also remember
> >> the version that we're using?
> > 
> > The file ecj_3.2RC5.jar is the exact binary download from eclipse.org
> > (renamed from their generic ecj.jar).  Prefixing with harmony_ probably
> > isn't appropriate, but I could pick-up the first ecj_*.jar that I find.
> 
> I guess ecj_* works too...
> 
> 
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [tools] tools launching and javac

[Geir Magnusson Jr <ge...@pobox.com>]

Mark Hindess wrote:
> On 25 May 2006 at 7:46, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> Tim Ellison wrote:
>>> Geir Magnusson Jr wrote:
>>>> Tim Ellison wrote:
>>>>> This is still work in progress, but thought it would be good to give a
>>>>> quick update on where I am at the moment:
>>> <snip>
>>>>> Now you can run javac.
>>>> Very cute!  Do you intend module/tools to remain not part of the build?
>>> It will become part of the build once it is as-good-as done.
>>>
>>> I'm trying to do a balancing act between /not/ dumping my junk into SVN
>>> as I go along, and developing in the open | collaboratively.
>>> Suggestions for re-balancing are more than welcome.
>> Only suggestion is to do a branches/tim/stuff1, work in there if you
>> want people to comment (with the bonus of having it in SVN in case of
>> problem).
>>
>> It's COW so the space usage won't be that bad, and you can just delete
>> when done.
> 
> While that's true, I think that development on branches has other costs:
> 
>  * merging back into trunk
> 
>  * fewer people will pay attention - nothing personal but I might be
>    less inclined to scan commits in branches/tim than trunk ;-)

Right, but right now he's not putting anything in trunk.  So you have no 
hope of seeing anything.

And it doesn't matter.  If you aren't interested in what he's doing, 
don't look at it.  if you are, you are engaged anyway.

> 
> Personally, I think development is moving fast enough that it's not a
> problem having it in trunk.  If it hadn't been in trunk, I might have
> been less inclined to test it ... and not had the incentive to fix the
> bugs (HARMONY-510) on my platform of choice.

Are we talking about two different things?  Tim was saying that he 
wanted to avoid dumping 'junk' into SVN, yet wants to work more in the open.

Working in a branch is a great way to do it.

> 
> Obviously, we should avoid breaking things like this for too long but I
> think the occasional breakage is a fair price to pay for not having the
> other costs.
> 
> Of course, I seem to be the only one who even noticed this problem.

Which problem?

It's going to be the case that people will want to go off into a 
'corner' and try something.  it's nice that they can do it so others can 
  watch, help, participate, and still it is out of the mainstream 
codebase until that person or people want to bring it in (or propose to 
bring it in).

The merging would be their problem, just as it would be if they were 
just working at home or in the office on a private copy.

The benefits seem obvious.

geir

> 
> Regards,
>  Mark.
> 
>>> <snip>
>>>
>>>>> - For now, the o.a.h.tools.javac.Main wrapper looks for the compiler in
>>>>> a hard-coded JAR filename (ecj_3.2RC5.jar).  Just wondering whether to
>>>>> embed that JAR in the tools.jar, or look for the compiler in *.jar, or
>>>>> ...?
>>>> Can we give it a 'known' pattern like "harmony_javac_ecj_3.2rc5.jar" or
>>>> such so we can mechanically find it w/o a long search, yet also remember
>>>> the version that we're using?
>>> The file ecj_3.2RC5.jar is the exact binary download from eclipse.org
>>> (renamed from their generic ecj.jar).  Prefixing with harmony_ probably
>>> isn't appropriate, but I could pick-up the first ecj_*.jar that I find.
>> I guess ecj_* works too...
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org