You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Alan D. Cabrera" <ad...@toolazydogs.com> on 2005/02/19 18:38:52 UTC
Consolidate snickers projects into runtime and compiler
I have merged all the ASN1 code into a unified multi-project maven setup
in asn1/branches/ber-decoder. I propose that we use this setup instead
of the project heirarchy that we have in trunk. All the code is neatly
in the modules directory. The maven site target now works correctly.
Finally, this setup paves the way for the ASN1 refactoring that has been
discussed on and off as of late.
Thoughts?
Regards,
Alan
Re: Consolidate snickers projects into runtime and compiler
Posted by Alex Karasulu <ao...@bellsouth.net>.
Alan D. Cabrera wrote:
> Thanks for the advice. Let's not go with what I proposed.
>
> I now have a new proposal, keep trunk the same except move my branch
> stuff into the trunk. We would have two new directories, runtime and
> compiler. Emmanuel and I can work on the new runtime in runtime.
>
> Thoughts?
I'm all for the runtime and compiler subproject consolidation. You got
the right idea here. Let's do it! But let's make sure we take the sum
total of ideas floating around. Meaning, factor in your ideas which
you have demonstrated in your ber-decoder branch and Emmanuel's ideas as
well as some of my own. Ideas which are pertinent to the issues of ASN1.
I think collaboratively we can arrive at what you are hoping for and
then some. Let's make sure this is our last rewrite for our ASN1
initiative. Let's make sure we have an architecture that only takes new
features and fixes to last us from now until the end of time. Of course
this is not always certain and a lofty goal however if we work together
patiently we can get really close. Let's make this current effort a
model of collaboration at directory which all other ASF projects run by.
Thanks,
-Alex
P.S. Please don't be dismayed by my reluctance to go to the new Maven
layout. I just don't want to introduce a new build configurations and
other factors as we try to grok the core issues here.
>
> Regards,
> Alan
>
> Brett Porter wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>I think the existing structure is closer to what is intended. It's not
>>perfect, but it's ok. Some problems with it:
>>- - src/images is should be in /xdocs/images, removing the need for src
>>altogether
>>- - maven.xml isn't adding anything and could be removed. It's just
>>aliasing some common tasks.
>>
>>The main problems with the refactoring:
>>- - the addition of a /modules/ directory is unnecessary. We generally
>>encourage most subdirectories being modules in an aggregated project
>>- - the parent etc directory is fine - separation of master build (at
>>the root) and inherited values (in etc). However, in this case the root
>>inherits also inherits etc, so there's no real point to separating them.
>>- - maven.xml is very lengthy and mostly unnecessary.
>>
>>Any use of maven.xml is really considered a "last resort". Part of the
>>intention of Maven is to make goals standard: whenever you pick up a
>>different project you shouldn't have to learn how to build it, you
>>should just know. You really don't want to have to write jelly code if
>>you don't have to :) Keep it simple, keep it standard. It's less work to
>>set up, and less learning for the end user.
>>
>>Multiple projects in Maven 1.x was really added very late and not really
>>tightly integrated - something that has been discussed a lot and central
>>to the design of Maven2.
>>
>>ApacheDS and Naming both follow a standard that I'd recommend. I've done
>>bits and pieces as I've looked at the others, but was wary of changing
>>too much when I'm not wholly familiar with the output in case I break
>>something, or take away soeone's favourite shortcut goals :)
>>
>>Cheers,
>>Brett
>>
>>Alan D. Cabrera wrote:
>>
>>
>>
>>>Alex Karasulu wrote:
>>>
>>>
>>>
>>>>Alan D. Cabrera wrote:
>>>>
>>>>
>>>>
>>>>>I have merged all the ASN1 code into a unified multi-project maven
>>>>>
>>>>>
>>setup in asn1/branches/ber-decoder. I propose that we use this setup
>>instead of the project heirarchy that we have in trunk. All the code is
>>neatly in the modules directory. The maven site target now works
>>correctly. Finally, this setup paves the way for the ASN1 refactoring
>>that has been discussed on and off as of late.
>>
>>
>>>>>Thoughts?
>>>>>
>>>>>
>>>>Sorry for taking too long to respond - I had to ask a few questions
>>>>
>>>>
>>and get answers regarding your approach with the new proposed maven layout.
>>
>>
>>>>I asked Jason Van Zyl and he does not consider this layout a standard
>>>>
>>>>
>>and *HIGHLY* recommends against using this approach. If Jason and Brett
>>do not recommend this then I don't want to go there. However the layout
>>thing has nothing to do with code consolidation or making the changes to
>>the architecture that you propose. Having subordinate runtime and a
>>compiler subprojects can still be the case using the current
>>multiproject setup we have. There is no need for layout changes.
>>
>>
>>>>If Brett supports it then I may consider it but after weeks of setting
>>>>
>>>>
>>up our build as it stands today I do not think he'll buy this new
>>configuration. He would have set us up this way day one.
>>
>>
>>>I'm confused, I do not see any work being done on the organization of
>>>
>>>
>>ASN1 sub-project. If there is a ADS standardization effort underway,
>>then I'm happy to follow that.
>>
>>
>>>Regards,
>>>Alan
>>>
>>>
>>>
>>>
>>>
>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.4.0 (Cygwin)
>>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>>iD8DBQFCGWdeOb5RoQhMkRMRAqSkAKCSoOYOibf7Mtg/XDEiYgD4NQ4VQACfS47F
>>ThO7k2clVMFPanICmgFri7w=
>>=gkNQ
>>-----END PGP SIGNATURE-----
>>
>>
Re: Consolidate snickers projects into runtime and compiler
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
Thanks for the advice. Let's not go with what I proposed.
I now have a new proposal, keep trunk the same except move my branch
stuff into the trunk. We would have two new directories, runtime and
compiler. Emmanuel and I can work on the new runtime in runtime.
Thoughts?
Regards,
Alan
Brett Porter wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I think the existing structure is closer to what is intended. It's not
>perfect, but it's ok. Some problems with it:
>- - src/images is should be in /xdocs/images, removing the need for src
>altogether
>- - maven.xml isn't adding anything and could be removed. It's just
>aliasing some common tasks.
>
>The main problems with the refactoring:
>- - the addition of a /modules/ directory is unnecessary. We generally
>encourage most subdirectories being modules in an aggregated project
>- - the parent etc directory is fine - separation of master build (at
>the root) and inherited values (in etc). However, in this case the root
>inherits also inherits etc, so there's no real point to separating them.
>- - maven.xml is very lengthy and mostly unnecessary.
>
>Any use of maven.xml is really considered a "last resort". Part of the
>intention of Maven is to make goals standard: whenever you pick up a
>different project you shouldn't have to learn how to build it, you
>should just know. You really don't want to have to write jelly code if
>you don't have to :) Keep it simple, keep it standard. It's less work to
>set up, and less learning for the end user.
>
>Multiple projects in Maven 1.x was really added very late and not really
>tightly integrated - something that has been discussed a lot and central
>to the design of Maven2.
>
>ApacheDS and Naming both follow a standard that I'd recommend. I've done
>bits and pieces as I've looked at the others, but was wary of changing
>too much when I'm not wholly familiar with the output in case I break
>something, or take away soeone's favourite shortcut goals :)
>
>Cheers,
>Brett
>
>Alan D. Cabrera wrote:
>
>
>
>>Alex Karasulu wrote:
>>
>>
>>
>>>Alan D. Cabrera wrote:
>>>
>>>
>>>
>>>>I have merged all the ASN1 code into a unified multi-project maven
>>>>
>>>>
>setup in asn1/branches/ber-decoder. I propose that we use this setup
>instead of the project heirarchy that we have in trunk. All the code is
>neatly in the modules directory. The maven site target now works
>correctly. Finally, this setup paves the way for the ASN1 refactoring
>that has been discussed on and off as of late.
>
>
>>>>Thoughts?
>>>>
>>>>
>>>
>>>Sorry for taking too long to respond - I had to ask a few questions
>>>
>>>
>and get answers regarding your approach with the new proposed maven layout.
>
>
>>>I asked Jason Van Zyl and he does not consider this layout a standard
>>>
>>>
>and *HIGHLY* recommends against using this approach. If Jason and Brett
>do not recommend this then I don't want to go there. However the layout
>thing has nothing to do with code consolidation or making the changes to
>the architecture that you propose. Having subordinate runtime and a
>compiler subprojects can still be the case using the current
>multiproject setup we have. There is no need for layout changes.
>
>
>>>If Brett supports it then I may consider it but after weeks of setting
>>>
>>>
>up our build as it stands today I do not think he'll buy this new
>configuration. He would have set us up this way day one.
>
>
>>
>>I'm confused, I do not see any work being done on the organization of
>>
>>
>ASN1 sub-project. If there is a ADS standardization effort underway,
>then I'm happy to follow that.
>
>
>>Regards,
>>Alan
>>
>>
>>
>>
>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.0 (Cygwin)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFCGWdeOb5RoQhMkRMRAqSkAKCSoOYOibf7Mtg/XDEiYgD4NQ4VQACfS47F
>ThO7k2clVMFPanICmgFri7w=
>=gkNQ
>-----END PGP SIGNATURE-----
>
>
Re: Consolidate snickers projects into runtime and compiler
Posted by Brett Porter <br...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think the existing structure is closer to what is intended. It's not
perfect, but it's ok. Some problems with it:
- - src/images is should be in /xdocs/images, removing the need for src
altogether
- - maven.xml isn't adding anything and could be removed. It's just
aliasing some common tasks.
The main problems with the refactoring:
- - the addition of a /modules/ directory is unnecessary. We generally
encourage most subdirectories being modules in an aggregated project
- - the parent etc directory is fine - separation of master build (at
the root) and inherited values (in etc). However, in this case the root
inherits also inherits etc, so there's no real point to separating them.
- - maven.xml is very lengthy and mostly unnecessary.
Any use of maven.xml is really considered a "last resort". Part of the
intention of Maven is to make goals standard: whenever you pick up a
different project you shouldn't have to learn how to build it, you
should just know. You really don't want to have to write jelly code if
you don't have to :) Keep it simple, keep it standard. It's less work to
set up, and less learning for the end user.
Multiple projects in Maven 1.x was really added very late and not really
tightly integrated - something that has been discussed a lot and central
to the design of Maven2.
ApacheDS and Naming both follow a standard that I'd recommend. I've done
bits and pieces as I've looked at the others, but was wary of changing
too much when I'm not wholly familiar with the output in case I break
something, or take away soeone's favourite shortcut goals :)
Cheers,
Brett
Alan D. Cabrera wrote:
>
>
> Alex Karasulu wrote:
>
>> Alan D. Cabrera wrote:
>>
>>> I have merged all the ASN1 code into a unified multi-project maven
setup in asn1/branches/ber-decoder. I propose that we use this setup
instead of the project heirarchy that we have in trunk. All the code is
neatly in the modules directory. The maven site target now works
correctly. Finally, this setup paves the way for the ASN1 refactoring
that has been discussed on and off as of late.
>>>
>>> Thoughts?
>>
>>
>>
>> Sorry for taking too long to respond - I had to ask a few questions
and get answers regarding your approach with the new proposed maven layout.
>>
>> I asked Jason Van Zyl and he does not consider this layout a standard
and *HIGHLY* recommends against using this approach. If Jason and Brett
do not recommend this then I don't want to go there. However the layout
thing has nothing to do with code consolidation or making the changes to
the architecture that you propose. Having subordinate runtime and a
compiler subprojects can still be the case using the current
multiproject setup we have. There is no need for layout changes.
>>
>> If Brett supports it then I may consider it but after weeks of setting
up our build as it stands today I do not think he'll buy this new
configuration. He would have set us up this way day one.
>
>
>
> I'm confused, I do not see any work being done on the organization of
ASN1 sub-project. If there is a ADS standardization effort underway,
then I'm happy to follow that.
>
>
> Regards,
> Alan
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCGWdeOb5RoQhMkRMRAqSkAKCSoOYOibf7Mtg/XDEiYgD4NQ4VQACfS47F
ThO7k2clVMFPanICmgFri7w=
=gkNQ
-----END PGP SIGNATURE-----
Re: Consolidate snickers projects into runtime and compiler
Posted by Alex Karasulu <ao...@bellsouth.net>.
Brett Porter wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I didn't realise there were other branches out there :)
>
>I made a few cleanups on the trunk yesterday - it might be worth porting
>them across to any branches (sorry, I didn't keep the changeset number,
>but it should be easy to find).
>
>Is this needed?
>
>
>
No problem I'll look through my commit notifications.
Thanks,
Alex
>- - Brett
>
>
>
>>I've been doing work slowly but surely towards this end. I created the
>>
>>
>rewrite branch to start pulling stuff from your branch into it and
>bringing in some of Emmanuel's ideas at the same time. I'd like to see
>us all working on this new branch which we use to replace the trunk.
>
>
>>Alex
>>
>>
>>
>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.0 (Cygwin)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFCGklaOb5RoQhMkRMRAj4DAJ9e9xsU8NeEIlqq8RUCTohH90EDiACgtyva
>vSlhcLlvffingJwpPEIwsIY=
>=kOYZ
>-----END PGP SIGNATURE-----
>
>
>
>
Re: Consolidate snickers projects into runtime and compiler
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
Brett Porter wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I didn't realise there were other branches out there :)
>
>I made a few cleanups on the trunk yesterday - it might be worth porting
>them across to any branches (sorry, I didn't keep the changeset number,
>but it should be easy to find).
>
>Is this needed?
>
>
Nope, not for what I need to move over.
>- - Brett
>
>
>
>>I've been doing work slowly but surely towards this end. I created the
>>
>>
>rewrite branch to start pulling stuff from your branch into it and
>bringing in some of Emmanuel's ideas at the same time. I'd like to see
>us all working on this new branch which we use to replace the trunk.
>
>
The beauty of our work is that much if it , IIUC, is orthogonal to each
other.
Regards,
Alan
Re: Consolidate snickers projects into runtime and compiler
Posted by Brett Porter <br...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I didn't realise there were other branches out there :)
I made a few cleanups on the trunk yesterday - it might be worth porting
them across to any branches (sorry, I didn't keep the changeset number,
but it should be easy to find).
Is this needed?
- - Brett
>
> I've been doing work slowly but surely towards this end. I created the
rewrite branch to start pulling stuff from your branch into it and
bringing in some of Emmanuel's ideas at the same time. I'd like to see
us all working on this new branch which we use to replace the trunk.
>
> Alex
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCGklaOb5RoQhMkRMRAj4DAJ9e9xsU8NeEIlqq8RUCTohH90EDiACgtyva
vSlhcLlvffingJwpPEIwsIY=
=kOYZ
-----END PGP SIGNATURE-----
Re: Consolidate snickers projects into runtime and compiler
Posted by Emmanuel Lecharny <el...@iktek.com>.
> > I'm confused, I do not see any work being done on the organization of
> > ASN1 sub-project. If there is a ADS standardization effort underway,
> > then I'm happy to follow that.
>
> I've been doing work slowly but surely towards this end. I created the
> rewrite branch to start pulling stuff from your branch into it and
> bringing in some of Emmanuel's ideas at the same time. I'd like to see
> us all working on this new branch which we use to replace the trunk.
Hi guys,
I'm actually working on this branch (rewrite). I think that we will have
a kind of three layers stuff at the end:
- stubs (generated by the compiler)
- digester or something like that
- BER/DER codec
Digester is the main point here. As Alex said in his wiki page, it
should be rewritten. Not that simple, because it carries all the
semantic of the LDAP grammar (and of others grammars).
The deeper you go, the more abstract you become. BER/DER codec should be
very context-free (no semantic at all, or at least, the semantic should
be carried by callbacks).
We have then two options here :
1) decode a TLV, even if it's a bad one
2) decode a TLV and check it immediatly (this is the way it's done
actually).
I think that the second option *must* be implemented to avoid a long
decoding of a twisted TLV.(a "fail fast" decoder).
The avantage of separating thoses three layers is that you just have to
agree on interfaces between them, and it gives you an opportinuty to
improve each layer separatly. Plus it allows to keep the whole thing
simple to deal with !
Pretty sure that Alan has a good work done on the compiler part.
Maybe we have to synchronize ourselves ?
Re: Consolidate snickers projects into runtime and compiler
Posted by Alex Karasulu <ao...@bellsouth.net>.
Alan D. Cabrera wrote:
>
>
> Alex Karasulu wrote:
>
>> Alan D. Cabrera wrote:
>>
>>> I have merged all the ASN1 code into a unified multi-project maven
>>> setup in asn1/branches/ber-decoder. I propose that we use this setup
>>> instead of the project heirarchy that we have in trunk. All the
>>> code is neatly in the modules directory. The maven site target now
>>> works correctly. Finally, this setup paves the way for the ASN1
>>> refactoring that has been discussed on and off as of late.
>>>
>>> Thoughts?
>>
>>
>>
>> Sorry for taking too long to respond - I had to ask a few questions
>> and get answers regarding your approach with the new proposed maven
>> layout.
>>
>> I asked Jason Van Zyl and he does not consider this layout a standard
>> and *HIGHLY* recommends against using this approach. If Jason and
>> Brett do not recommend this then I don't want to go there. However
>> the layout thing has nothing to do with code consolidation or making
>> the changes to the architecture that you propose. Having subordinate
>> runtime and a compiler subprojects can still be the case using the
>> current multiproject setup we have. There is no need for layout
>> changes.
>>
>> If Brett supports it then I may consider it but after weeks of
>> setting up our build as it stands today I do not think he'll buy this
>> new configuration. He would have set us up this way day one.
>
>
>
> I'm confused, I do not see any work being done on the organization of
> ASN1 sub-project. If there is a ADS standardization effort underway,
> then I'm happy to follow that.
I've been doing work slowly but surely towards this end. I created the
rewrite branch to start pulling stuff from your branch into it and
bringing in some of Emmanuel's ideas at the same time. I'd like to see
us all working on this new branch which we use to replace the trunk.
Alex
Re: Consolidate snickers projects into runtime and compiler
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
Alex Karasulu wrote:
> Alan D. Cabrera wrote:
>
>> I have merged all the ASN1 code into a unified multi-project maven
>> setup in asn1/branches/ber-decoder. I propose that we use this setup
>> instead of the project heirarchy that we have in trunk. All the code
>> is neatly in the modules directory. The maven site target now works
>> correctly. Finally, this setup paves the way for the ASN1
>> refactoring that has been discussed on and off as of late.
>>
>> Thoughts?
>
>
> Sorry for taking too long to respond - I had to ask a few questions
> and get answers regarding your approach with the new proposed maven
> layout.
>
> I asked Jason Van Zyl and he does not consider this layout a standard
> and *HIGHLY* recommends against using this approach. If Jason and
> Brett do not recommend this then I don't want to go there. However
> the layout thing has nothing to do with code consolidation or making
> the changes to the architecture that you propose. Having subordinate
> runtime and a compiler subprojects can still be the case using the
> current multiproject setup we have. There is no need for layout changes.
>
> If Brett supports it then I may consider it but after weeks of setting
> up our build as it stands today I do not think he'll buy this new
> configuration. He would have set us up this way day one.
I'm confused, I do not see any work being done on the organization of
ASN1 sub-project. If there is a ADS standardization effort underway,
then I'm happy to follow that.
Regards,
Alan
RE: Consolidate snickers projects into runtime and compiler
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I asked Jason Van Zyl and he does not consider this layout a standard
> and *HIGHLY* recommends against using this approach.
Do we have e-mail for this?
--- Noel
Re: Consolidate snickers projects into runtime and compiler
Posted by Alex Karasulu <ao...@bellsouth.net>.
Alan D. Cabrera wrote:
> I have merged all the ASN1 code into a unified multi-project maven
> setup in asn1/branches/ber-decoder. I propose that we use this setup
> instead of the project heirarchy that we have in trunk. All the code
> is neatly in the modules directory. The maven site target now works
> correctly. Finally, this setup paves the way for the ASN1 refactoring
> that has been discussed on and off as of late.
>
> Thoughts?
Sorry for taking too long to respond - I had to ask a few questions and
get answers regarding your approach with the new proposed maven layout.
I asked Jason Van Zyl and he does not consider this layout a standard
and *HIGHLY* recommends against using this approach. If Jason and Brett
do not recommend this then I don't want to go there. However the layout
thing has nothing to do with code consolidation or making the changes to
the architecture that you propose. Having subordinate runtime and a
compiler subprojects can still be the case using the current
multiproject setup we have. There is no need for layout changes.
If Brett supports it then I may consider it but after weeks of setting
up our build as it stands today I do not think he'll buy this new
configuration. He would have set us up this way day one.
Thanks,
Alex
Re: Consolidate snickers projects into runtime and compiler
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
Emmanuel Lecharny wrote:
>>I use IntelliJ and am not familiar w/ Eclipse. Eclipse can read maven
>>and project files?
>>
>>
>
>Yes, thanks to Brett. Actually, with asn.1, what I'm doing is :
>1) co the trunk
>2) maven -Dmaven.eclipse.workspace=/<my workspace> -Dgoal=eclipse
>multiproject:goal
>3) 13 seconds after, I can import the generated projets into eclipse
>(you better have the MultiProject Import plugin installed !!!), and
>that's it !
>4) With the mevenide plugin, you can launch goals, check project.xml and
>maven.xml, ...
>
>At least, it works for asn.1, and only asn.1 :(
>
>For other projects, that's quite different. LDAP is almost OK, but it
>need some fix to generate antlr BEFORE generating .projects files (it's
>a kind of prerequiste : you need the java files)
>
>Apache is much more complicated : run Maven multiproject, then
>'mavenize' again (mavenize is a script I wrote that does the eclipse
>generation). Antlr should run before, then the maven plugin to generate
>schema, and then, you are ready !
>
>It does not work for MINA, SEDANG and APSEDA, but I didn't investigate
>the processus, as I don't need them actually.
>
>
Odd, I thought this was a standard multiproject setup. I wonder what's
wrong with it.
Re: Consolidate snickers projects into runtime and compiler
Posted by Emmanuel Lecharny <el...@iktek.com>.
> This is just a branch name. My proposal is to replace the setup in
> the trunk w/ this setup.
OK, that's perfect ! I forgot that it was a branche ...
> This is a mixture of old modules and new modules . I imagine that
> once we're done, we would only have two modules compiler and runtime.
I buy this idea. compiler and runtime, that sound good !
> I use IntelliJ and am not familiar w/ Eclipse. Eclipse can read maven
> and project files?
Yes, thanks to Brett. Actually, with asn.1, what I'm doing is :
1) co the trunk
2) maven -Dmaven.eclipse.workspace=/<my workspace> -Dgoal=eclipse
multiproject:goal
3) 13 seconds after, I can import the generated projets into eclipse
(you better have the MultiProject Import plugin installed !!!), and
that's it !
4) With the mevenide plugin, you can launch goals, check project.xml and
maven.xml, ...
At least, it works for asn.1, and only asn.1 :(
For other projects, that's quite different. LDAP is almost OK, but it
need some fix to generate antlr BEFORE generating .projects files (it's
a kind of prerequiste : you need the java files)
Apache is much more complicated : run Maven multiproject, then
'mavenize' again (mavenize is a script I wrote that does the eclipse
generation). Antlr should run before, then the maven plugin to generate
schema, and then, you are ready !
It does not work for MINA, SEDANG and APSEDA, but I didn't investigate
the processus, as I don't need them actually.
Re: Consolidate snickers projects into runtime and compiler
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
Emmanuel Lecharny wrote:
>Hi alan,
>
>Le samedi 19 février 2005 à 12:38 -0500, Alan D. Cabrera a écrit :
>
>
>>I have merged all the ASN1 code into a unified multi-project maven setup
>>in asn1/branches/ber-decoder.
>>
>>
>
>I'm just a little bit reluctant about the name : Ber-decoder. As it
>includes a Der decoder, it would be better if named asn1-decoder or
>something ASN1 related.
>
>
This is just a branch name. My proposal is to replace the setup in the
trunk w/ this setup.
>>I propose that we use this setup instead
>>of the project heirarchy that we have in trunk. All the code is neatly
>>in the modules directory.
>>
>>
>
>Is this a "must" thing to put all the projects under a module
>subdirectory? Does a separation between what is used to generate stubs
>and what is used by other projects (I mean, codecs) make sense?
>
>
This is a mixture of old modules and new modules . I imagine that once
we're done, we would only have two modules compiler and runtime.
>>The maven site target now works correctly.
>>Finally, this setup paves the way for the ASN1 refactoring that has been
>>discussed on and off as of late.
>>
>>
>
>hem, I was able to generate .project files for eclipse with the previous
>Maven & project.xml in trunk, not anymore in ber-decoder branches. That
>is not such a big deal, but it would be real cool if this feature still
>work !
>
>
I use IntelliJ and am not familiar w/ Eclipse. Eclipse can read maven
and project files?
Regards,
Alan
Re: Consolidate snickers projects into runtime and compiler
Posted by Emmanuel Lecharny <el...@iktek.com>.
Hi alan,
Le samedi 19 février 2005 à 12:38 -0500, Alan D. Cabrera a écrit :
> I have merged all the ASN1 code into a unified multi-project maven setup
> in asn1/branches/ber-decoder.
I'm just a little bit reluctant about the name : Ber-decoder. As it
includes a Der decoder, it would be better if named asn1-decoder or
something ASN1 related.
> I propose that we use this setup instead
> of the project heirarchy that we have in trunk. All the code is neatly
> in the modules directory.
Is this a "must" thing to put all the projects under a module
subdirectory? Does a separation between what is used to generate stubs
and what is used by other projects (I mean, codecs) make sense?
> The maven site target now works correctly.
> Finally, this setup paves the way for the ASN1 refactoring that has been
> discussed on and off as of late.
hem, I was able to generate .project files for eclipse with the previous
Maven & project.xml in trunk, not anymore in ber-decoder branches. That
is not such a big deal, but it would be real cool if this feature still
work !
>
> Thoughts?
that's it. No more thoughts...
>
>
> Regards,
> Alan
>
>
>